How fast is QuestDB for time-series ingestion and queries?

QuestDB's published benchmark figures put it in the high-throughput, low-latency tier: 19M rows/sec/server ingestion, 220M rows/sec streamed to Arrow, 2.3s to stream 500M rows, and 32ms to the first Arrow batch. These numbers come from QuestDB's published QWP benchmark results on QuestDB v10.0, and they describe a specific workload rather than a universal guarantee. Use them as a reference point for whether QuestDB's architecture fits your throughput and latency targets, then validate against your own data shape and query patterns.

The headline numbers

Two things are worth separating here. The ingestion figure describes how fast events land in the database. The Arrow figures describe how fast stored data moves out to an analytics consumer. They stress different parts of the system, so a workload that is write-heavy and a workload that is read-heavy will each care about a different row above.

What the numbers actually measure

Ingestion (19M rows/sec/server). This is a per-server figure for sustained event intake. QuestDB states it ingests millions of events per second, and the benchmark figure is the concrete version of that claim. The relevant question for you is whether your peak event rate fits inside one server's budget with headroom, or whether you need to shard across servers.

Streaming to Arrow (220M rows/sec, 2.3s for 500M rows, 32ms to first batch). These describe the path from stored data to Apache Arrow, the columnar format used by many analytics and ML tools. The 32ms first-batch number matters more than the total throughput number for interactive work: it tells you how quickly a consumer starts receiving data rather than how fast the whole transfer finishes. The 2.3s figure is the end-to-end time for a 500M-row transfer.

Why the architecture produces these numbers

QuestDB's positioning is a single SQL engine spanning messaging, stream processing, and tiered storage, with data exposed through open formats including Apache Parquet, Iceberg, and Arrow. That combination is what the benchmark is exercising:

• Columnar, time-partitioned storage keeps ingestion append-heavy and makes time-range scans cheap.
• Open-format output (Parquet, Iceberg, Arrow) means the same record that was just ingested can be handed to an external engine without an export step.
• One SQL engine over live and historical data avoids a separate stream-processing tier for many queries.

The practical consequence: you can ingest ticks, orders, and executions, compute on them while the market is moving, and run historical analysis in SQL over the same table — without copying data between systems.

How to decide whether this is fast enough

Match the benchmark to your own bottleneck:

• Write-bound? Compare your peak events/sec against 19M rows/sec/server, then discount for your row width, indexing, and durability settings. Deduplication and out-of-order correction are built in, and both cost something.
• Read-bound on large scans? The Arrow streaming numbers are the relevant ones. If your consumers already speak Arrow, Parquet, or Iceberg, the open-format path is the one to test.
• Latency-sensitive on live data? QuestDB claims millisecond computation on live data. The 32ms first-batch figure is the closest published proxy for time-to-first-result on a large transfer.

Benchmarks are configuration-specific. The honest test is to load a representative slice of your own data — same row width, same cardinality, same query mix — and measure ingestion rate, p99 query latency, and time-to-first-Arrow-batch on hardware comparable to your target.

Where these figures come from

The numbers above are QuestDB's published QWP benchmark results on QuestDB v10.0, as stated on questdb.com. QuestDB also reports that the system runs in banks, exchanges, aerospace and robotics, and energy and infrastructure settings, with a cited case of 7,000+ queries/second at national scale for 90M users. Those are vendor-published claims; treat them as a starting hypothesis and confirm with your own workload before committing.