QuestDB 10 Is Now the Default on Layerbase Cloud
Short version: new QuestDB databases on Layerbase Cloud run 10.0.1 as of today. The big items in 10.0 are QWP (a binary columnar wire protocol over WebSockets), Live Views, and a notebook-style Web Console. Nothing changes about how you connect here: it is still the PostgreSQL wire protocol on port 5432, so every existing driver and dashboard works untouched. Databases already on 9.2 or 9.4 stay on 9.2 or 9.4.
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 7a391566ac827e0d8c269b91f2415c16b0a32a84FAQ
Will my existing QuestDB database be upgraded to 10?
No. The version you created on is the version you keep until you decide otherwise. 9.2 and 9.4 both stay fully supported for start, stop, backup, restore, and even creating new databases on that line. A major version bump you did not schedule is an incident, not an upgrade.
Do I need to change my connection code for QuestDB 10?
Not on Layerbase. You still connect over the PostgreSQL wire protocol on port 5432, which did not change in this release. QWP is new surface area we have not wired through our connection layer, so we are not claiming it yet.
What is QWP and can I use it today?
It is a binary, columnar protocol over WebSockets that carries ingestion and query results on one connection, shipping typed compressed columns instead of the key=value text pairs ILP sends. Client support is uneven: Java, C/C++, Rust, and Python are full, Go and .NET are beta, and Node.js has not shipped. ILP and PG wire both remain supported.
What breaks in QuestDB 10 if I have tooling that introspects the database?
Four things. SHOW PARTITIONS gained two trailing columns, so anything binding result columns by position needs updating. pg_class.relkind and information_schema.tables.table_type now report the real object kind instead of one blanket value. EXPLAIN over HTTP and CSV returns plain text rather than HTML-escaped output. And out-of-range RANGE window frame bounds are a compile-time error instead of silently wrapping.
Does QuestDB scale to zero on Layerbase?
No, and that is deliberate. QuestDB is one of our always-on Performance engines, so it does not hibernate and there is no JVM cold start in front of your first query of the morning. It runs on the Pro plan; the pricing page has the current number.
Why 10.0.1 and not 10.0.0?
Because a .0 of a major release is where the sharp edges live. 10.0.1 is a couple dozen fixes across SQL, storage, and the web console with nothing new added to destabilize it, which made it the version worth defaulting to.
If 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
- The InfluxDB 3 Core 72-hour query limit: what it is, why it exists, and your two ways outInfluxDB 3 Core refuses queries that touch more than 432 Parquet files, which at the default 10-minute file duration works out to about 72 hours of data per query. The data is still there. Here is the mechanism, the knob, what Layerbase actually runs, and the two honest exits.
- Timescale is TigerData now: where to take a time-series workloadTimescale rebranded to TigerData, the cloud is Tiger Cloud, and the extension is still called TimescaleDB. If you use hypertables we are not your migration path, and this post explains exactly why. If you are on Tiger Cloud running ordinary Postgres, or you want managed time-series without an extension license in the middle, read on.
- 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.