QuestDB 10 Is Now the Default on Layerbase Cloud
QuestDB shipped 10.0.0 on August 6 and followed it with the 10.0.1 maintenance release on August 24. We deliberately waited for that first patch before moving: a .0 of a major release is where the sharp edges live, and 10.0.1 is a couple dozen fixes across SQL, storage, and the web console with nothing new to destabilize it.
As of today, a new QuestDB database on Layerbase Cloud runs 10.0.1. If you already run QuestDB on Layerbase, nothing happened to you, and the second half of this post explains exactly what that means.
What is actually in QuestDB 10
Three headline features, and a long tail of fixes.
QWP, the QuestDB Wire Protocol. A binary, columnar protocol over WebSockets that carries both directions of the workload on one connection: rows in, query results out. QuestDB's numbers for it are striking, tens of millions of rows per second of ingestion on a single connection and query egress in excess of 200M rows/second, because the protocol ships typed, compressed columns instead of the key=value text pairs ILP sends. It also brings store-and-forward buffering on the client, so a network drop no longer means lost rows. ILP and the PostgreSQL wire protocol both remain supported, and QuestDB's own guidance is that they stay around for compatibility.
One caveat worth knowing before you plan around it: the official client support matrix has Java, C/C++, Rust, and Python at full QWP support, Go and .NET at beta, and Node.js not yet shipped.
Live Views. A live view incrementally maintains a window-function result set with millisecond update latency, the way materialized views already do for aggregations. If you have ever polled a SAMPLE BY query on a timer to feed a dashboard, this is the feature that replaces the timer. It is marked beta in 10.0.
Web Console 2.0. The bundled console gets Jupyter-style notebooks (text, code, live charts in one document) and MCP integration for coding agents.
The release notes cover the rest: SHOW CREATE DATABASE as a schema-only logical dump, opt-in per-query memory limits, and ALTER COLUMN TYPE working on Parquet-partitioned tables, which pairs nicely with the table-level Parquet format we wrote about when 9.4 shipped.
What changes when you connect to a Layerbase QuestDB: nothing
The way you talk to a QuestDB database on Layerbase today is the PostgreSQL wire protocol on port 5432, exactly as before. Every driver, dashboard, and script that worked against a 9.4 database works unchanged against a 10.0 one, because PG wire did not change in this release. QWP is new surface area we have not wired through our connection layer yet, so we are not claiming it; when we do, it will get its own post with the verification to back it.
If you carry tooling that introspects QuestDB, four breaking changes in 10.0 are worth a scan:
SHOW PARTITIONSgained two trailing columns (seqTxn,isRemotelyServed), so anything binding result columns by position needs updating.pg_class.relkindandinformation_schema.tables.table_typenow report the actual object kind instead of one blanket value, aligning with PostgreSQL semantics.EXPLAINover HTTP and CSV returns plain text rather than HTML-escaped output.- Out-of-range
RANGEwindow frame bounds are now a compile-time error instead of silently wrapping.
None of these touch normal ingestion or querying, which is why we were comfortable making 10.0 the default rather than an opt-in.
Already on 9.x? Nothing moves underneath you
Databases already running 9.2 or 9.4 on Layerbase stay on 9.2 or 9.4. The version you created on is the version you keep until you decide otherwise, and both lines remain fully supported: start, stop, backup, restore, and creating a new database on 9.4 all still work if you have a reason to stay on the line your tooling is validated against. The only thing that changed is the default in the version picker for new databases.
That policy is deliberate. A major version bump in a database you did not schedule is an incident, not an upgrade.
Verified, not assumed
Before flipping the default we ran the release through the same gate every engine version gets here: the binary boots and serves on every platform we build for, backup and restore round-trip, and a live database on our staging fleet answers for itself. For the curious, SELECT build() on a freshly created database returns:
Build Information: QuestDB 10.0.1, JDK 25.0.2, Commit Hash 7a391566ac827e0d8c269b91f2415c16b0a32a84If you want a managed QuestDB with a signup form instead of a sales call, the 2026 landscape post explains why Layerbase is currently the only self-serve option, and layerbase.com/create/questdb will have you on 10.0.1 in under a minute.
Keep reading
- Branching time-series databasesNobody branches a time-series database. Neon branches Postgres, PlanetScale branches MySQL, and telemetry data gets a stale CSV sample. QuestDB and InfluxDB branch on Layerbase now, and it changes how you test against real metrics.
- QuestDB 9.4: Time-Series Partitions You Can Store as ParquetQuestDB 9.4 lets a table declare Parquet as its partition format at CREATE TABLE time. Here is what Parquet actually is, why a time-partitioned table is the ideal shape for it, and how the feature behaves on a real database.
- QuestDB Cloud Is Gone. Here's Where to Run QuestDB Now.QuestDB Cloud is discontinued and the official path is a sales-gated Enterprise/BYOC product. If you want managed QuestDB with a signup form instead of a sales call, here is the 2026 state of play.
- QuestDB Cloud is gone. Here is what to use instead.QuestDB retired its self-serve cloud for Enterprise BYOC. If you want a managed QuestDB instance without a sales call, here are the options that still exist.