August 2026 Summaries

QuestDB reports an informal, reproducible benchmark focused on database egress performance, measuring how quickly 500 million unfiltered trade rows can be streamed to Python clients as Apache Arrow rather than how quickly they can be queried. On cache-resident data across separate AWS database and client hosts, QuestDB’s WebSocket-based QWP protocol streamed about 220 million rows per second with eight readers, delivering an initial Arrow batch in 32 milliseconds; a later reader sweep reached 266 million rows per second at 12 readers. ClickHouse’s native protocol reached roughly 142 million rows per second when run through separate processes, but buffered about 18 GB of client memory and returned no data until the full result was ready, while ClickHouse’s fastest streaming Arrow route reached about 94 million rows per second and TimescaleDB’s ADBC path about 14 million. QuestDB’s advantage in this dataset was partly attributed to its dictionary-encoded low-cardinality SYMBOL columns, which reduced network bytes per row, though the authors note that high-cardinality strings or different schemas could change the outcome. The investigation also found that early results were distorted by insufficient RAM causing disk reads, Python’s GIL constraining threaded ClickHouse native clients, and connection-coordination overhead rather than network or CPU saturation; it acknowledges limitations including a partially loaded TimescaleDB dataset, one workload and hardware configuration, and the fact that the benchmark was conducted by QuestDB’s vendor.

QuestDB 10.0 introduces the QuestDB Wire Protocol (QWP), a binary, columnar WebSocket protocol that unifies high-speed data ingestion and query retrieval through one client interface while retaining compatibility with existing InfluxDB Line Protocol and PostgreSQL wire connections. The release reports network ingestion around 3.6 times faster than ILP and Apache Arrow query-result streaming up to 220 million rows per second, enabling efficient zero-copy use with tools such as pandas and Polars, alongside client-side buffering, disk-backed store-and-forward, and failover support. It also adds beta live views that incrementally maintain window-function results in memory, advances Parquet into a native storage format with schema evolution and broader Iceberg ecosystem compatibility, and lays foundations for Enterprise cold storage that tiers readable Parquet partitions to object storage. Other additions include Web Console 2.0 notebooks with optional coding-agent integration through MCP, parallel covering-index decoding, new SQL capabilities, configurable per-query memory limits, improved cancellation and WAL recovery, and numerous correctness fixes discovered through continuous SQL fuzzing and fault injection.

QuestDB has introduced the QuestDB Wire Protocol (QWP), a binary, columnar WebSocket-based protocol intended to complement its existing InfluxDB Line Protocol (ILP) ingestion support and provide a unified client interface for both writing and querying time-series data. In TSBS benchmarks on AWS hardware, QWP frames averaged about 97 bytes per row compared with 347 bytes for ILP, reducing network use and allowing prebuilt QWP data to reach roughly 19 million rows per second over a network versus ILP’s 5.3 million, while local tests reached 48 million rows per second at lower cardinality and 33 million at one million distinct series. The report notes that standard co-located TSBS tests can obscure QWP’s advantage because the benchmark stores ILP in ready-to-send form but requires QWP rows to be encoded during timed execution, making the loader rather than the database or protocol a limiting factor. QWP maintained near-constant network throughput across up to one million series through session-level dictionary encoding of repeated symbols, although server-side performance declined somewhat at high cardinality when network bandwidth was not the bottleneck. For queries, QWP returns columnar batches and performed especially well for larger result sets relative to PostgreSQL wire and HTTP interfaces, while also supporting streaming Apache Arrow results. QuestDB positions QWP as an additional option rather than a replacement for ILP, citing compatibility, local buffering and replay, and failover capabilities, while advising users to test performance against their own workloads.