QuestDB 10.0 Ships QWP, a Binary Protocol Unifying Writes and Arrow Reads Over a Single Connection
QuestDB 10.0 introduces QWP, a binary columnar protocol that replaces separate ILP and PostgreSQL wire connections, cutting ingestion overhead and streaming query results into Apache Arrow at over 200 million rows a second.
Overview
QuestDB released version 10.0.0 of its open-source time-series database on August 6, 2026, headlined by a new wire protocol that lets a single client connection handle both writes and query results, according to the release notes on GitHub. The release is the first major version after the 9.4.x line, and its central addition — QWP, the QuestDB Wire Protocol — is designed to replace the two separate protocols the database previously relied on: the InfluxDB Line Protocol (ILP) for ingesting data and the PostgreSQL wire protocol for reading it back out.
What We Know
QWP is described in the GitHub release as “compressed binary, columnar, and pipelined over WebSockets,” running on the database’s existing HTTP port so operators do not need to open a new one. The company’s release announcement frames the change as closing a long-standing gap: “Fast ingestion is what QuestDB is known for. Getting the data back out at the same speed was the harder problem, and for years the answer was the PostgreSQL wire protocol, which was never designed for it.”
On the ingestion side, QuestDB benchmarked QWP against ILP using the Time Series Benchmark Suite (TSBS), finding QWP roughly 3.6x faster over a network and 3.1x faster on a single machine at one million distinct series. The company attributes the gain mostly to message size: “A TSBS row is around 347 bytes as line protocol text and around 97 bytes as QWP,” and since both protocols were run against the same 14.7 Gbit/s link, the smaller QWP rows pushed through faster, according to the blog post. The GitHub release notes separately put the compression gain at “3-4x less space” versus ILP under the TSBS schema.
On the read side, QuestDB says QWP streams query results directly into Apache Arrow at 220 million rows a second, a figure the GitHub release notes describe as “in excess of 200M rows/second, with first-batch latency of a handful of milliseconds.” In a separate benchmark draining a 500-million-row table into Arrow against ClickHouse and TimescaleDB on the same hardware, the company reports QWP at 1.55x the speed of ClickHouse’s fastest native configuration and 2.35x its fastest Arrow-streaming configuration, with the full 500 million rows drained in 2.3 seconds and the first Arrow batch landing after 32 milliseconds. QuestDB also says it moves the fewest bytes per row among the engines tested — 18.8, against 21.4, 27.0, and 64.3 for the others — because its SYMBOL columns cross the wire as dictionaries rather than repeating strings.
QWP client support varies by language at launch. The GitHub release notes list full support for Java, C/C++, Rust, and Python; beta support for Go and .NET; and note that Node.js support is listed as “Coming in a later release.” Crucially, both sources stress that the older protocols are not going away: “ILP and the PostgreSQL wire protocol are both still here, still supported, and nothing you run today stops working when you upgrade,” the company wrote, adding that a Telegraf agent or Grafana datasource pointed at QuestDB “keeps working exactly as before.”
QWP writes also gain a store-and-forward mechanism. Per the GitHub release notes, the client buffers rows locally before streaming them and replays them after a network disconnect, with three configurable durability modes — a default memory mode that survives process restarts but not power loss, a periodic mode that checkpoints to disk on a cadence, and a request_durable_ack mode that waits for end-to-end confirmation from the server. Clients can also be configured with multiple server addresses and automated failover to a backup node.
The release adds two other headline features. Live Views, shipping in beta, incrementally maintain window-function results — such as a rolling trade average — with millisecond update latency, using WAL-table backing for durability. The company describes them as complementary to QuestDB’s existing materialized views, which cover aggregations rather than window functions. Separately, the bundled Web Console moves to version 2.0 with a new notebooks feature and a Model Context Protocol (MCP) server that lets coding agents — the company names Claude Code, Codex, and Cursor as supported clients — read a database’s schema, run SQL, and build chart cells inside a user’s open browser session. The company says agent access runs entirely through the browser session already open, “so it never gets your database credentials,” with pairing gated behind a consent dialog and permissions starting read-only.
10.0 also carries a performance follow-up to the covering-index feature introduced in version 9.4.0: decoding covered columns now runs across multiple worker threads instead of one, which the company’s internal benchmark — 20 million rows, 8 workers, 10% selectivity — put at speedups ranging from 3.0x to 3.8x depending on query shape, according to the release announcement. The release notes also list a sorting-performance improvement that took a ClickBench query from 52 milliseconds to 37 milliseconds, plus new SQL functions including kurtosis() and skewness() aggregates and support for scalar sub-queries in comparison predicates.
The release includes several breaking changes documented in the GitHub release notes: the SHOW PARTITIONS command gains two trailing columns that will affect tools binding results by column position, EXPLAIN output over HTTP and CSV now returns unescaped plain text instead of HTML-escaped text, and any external SecurityContext implementation must now supply two new authorization methods for Live View creation and deletion.
What We Don’t Know
QuestDB’s own account of the QWP benchmarks says fuller methodology posts exist for both the ingestion and egress results, with the egress post described as following “shortly” after the ingestion one — meaning independent replication of the specific 3.6x and 220-million-row figures beyond the company’s own numbers is not yet available. The blog post also references a paid QuestDB Enterprise 4.0 release, including a cold-storage tier that moves partitions to object storage, as arriving separately “in the next few days”; that is a distinct commercial product from the open-source 10.0 release covered here and had not shipped as of this release’s publication.
Analysis
The protocol consolidation targets a specific pain point for time-series workloads: pulling large result sets out of a database fast enough to feed downstream analysis tools like Polars or Pandas without a row-by-row deserialization step in between. By routing both ingestion and Arrow-formatted query results through one binary connection, QuestDB is betting that operators managing high-frequency data — the release notes cite trading and “mission control” use cases — will value one dependency and one connect string over the flexibility of separate, more widely supported protocols. The company’s decision to keep ILP and the PostgreSQL wire protocol fully supported alongside QWP suggests an incremental-adoption strategy rather than a forced migration, letting existing integrations such as Telegraf and Grafana continue operating unchanged while newer clients opt into the faster path.