Benchmark report

How fast KDB is against QuestDB and PostgreSQL on the same PC, and what each engine change of 2026-09-23 gave, including where KDB is still slower and what is not measured.

• Category: Quality
• Keywords: benchmark report, benchmarks, speed, performance, how fast, QuestDB, PostgreSQL, KDB vs QuestDB, KDB vs PostgreSQL, rows per second, p50, latency, result cache, memory footprint, disk footprint, full-text search speed, news search, floor sheet, keyless, table locks, group commit, zone maps, saved stats, column mask, warm at open, A/B, index speed, slow parts, known slow, not measured
• See also: About KDB, Test report, Performance tips, Indexes, Full-text search, PostgreSQL protocol (port 8832), Limits

Every number on this page comes from a report or result file in the KDB source folder, named under each section. Nothing is rounded beyond what those files say.

Two kinds of measurement are on this page:

• Head-to-head: KDB and another database answer the same question on the same PC, and the answers are compared before the times.
• KDB-only A/B: the same KDB question before and after one change, the two builds interleaved in the same minutes. These say how much a change gave, not how KDB stands against anyone.

Setup

• Machine: Intel Core i9-14900HX, 32 threads, 32 GB RAM, Windows 11, the same disk for both databases.
• KDB: 0.2.0-dev, Release build, usually --sync-commits batch (QuestDB does not flush every commit either).
• Fair rules: the same client for both databases, every write timed until the rows can be read back, and row counts and checksums compared so both answered the same question. A benchmark checks "truncated": /exec answers at most 10,000 rows unless limit is passed.
• Docker: on 2026-09-23 the opponents ran in throwaway Docker containers, so every request to them crossed Docker Desktop's network. Their single-request numbers are much lower than on 2026-09-12, when they ran natively. Compare within one day, not across days.

KDB vs QuestDB: time-series, 2026-09-12

Head-to-head. Writes (rows per second, higher is better). The two QuestDB numbers are its results in the cache-off and the cache-on round.

Queries (p50 milliseconds at the client, including HTTP and JSON; lower is better).

• Writes: KDB won every test, from 1.1x to 21x, and it can delete rows, which QuestDB cannot.
• Queries with the cache on (the normal setting): KDB won every test; LATEST ON is a tie. It answered 12x more parallel queries.
• Queries with the cache off (the engine alone): KDB won 6 of 8. It was slower on count + sum over all rows and on LATEST ON. (count + sum of a whole table is now answered from saved stats; not re-measured against QuestDB with the cache off.)
• First run of a query: QuestDB 1.0-7.6 ms, KDB 0.43-4.7 ms.

Source: reports/benchmark-vs-questdb.md, bench/results/2026-09-12-clean-cache-off.json, bench/results/2026-09-12-clean-cache-on.json.

KDB vs QuestDB: time-series re-run, 2026-09-23

Head-to-head, one run per size, QuestDB in Docker, KDB with --memory 4096 and the harness's default result cache (on). Only the writes are shown: the query lines of these runs are cache hits on the KDB side, and every QuestDB request paid Docker's network.

At 100,000 and 2,000,000 rows the order is the same (bulk load 1,427,713 against 418,983, and 997,864 against 668,739 rows per second). Read this as "KDB's writes did not get slower since 2026-09-12", not as a new margin.

Source: bench/results/2026-09-23-100k.json, bench/results/2026-09-23-1m.json, bench/results/2026-09-23-2m.json.

Floor sheet: KDB vs QuestDB

Load, head-to-head, 2026-09-23. 814,535 real trades (15 days), 8 columns with three SYMBOL columns, PARTITION BY DAY, 20,000 rows per POST /write, medians of 7 alternating rounds.

Queries, head-to-head, 2026-09-22, in the container on real data (1,530,394 trades over 30 days), cache=0, every answer equal to QuestDB's:

The UNION ALL form went from 3.6x slower to 1.9x faster: each part is now grouped in the column engine before the parts are added up.

Found on the way: QuestDB 10.0.1 lost the first 20,000-row request after a DROP TABLE and CREATE TABLE of the same name, in 5 of 6 cycles, while answering 204 to it. Benchmarks now use a fresh table name per round.

Source: reports/keyless-runs.md, bench/results/2026-09-23-1m.json, reports/floorsheet-filter-speed.md.

News search: KDB vs PostgreSQL

Head-to-head, 2026-09-23. 200,000 articles (a title of 8 words, a body of 250 words, 378 MB of text), 21 runs per query. PostgreSQL 18.6 gets its best practice: a stored tsvector column with a GIN index, searched with the simple configuration (no stemming, like KDB). KDB gets CREATE FULLTEXT INDEX on title and body. Top-20 lists are ranked differently by design (BM25 against ts_rank_cd), so those are compared on row count only.

• Before the fixes of that day, on 20,000 shorter articles, a common-word count took 351 ms in KDB against 2.5 ms in PostgreSQL. Three faults caused it (a planner that dropped the index for common words, count(*) fetching every row, LIMIT not reaching the index). All three are fixed.
• The phrase line: word positions were added to the index the same afternoon. The 9.7 ms was measured with a sanitizer build and a fuzz run on the PC; a quiet re-run is owed. The phrase counts differ by 3 rows (2,376 against 2,379) because PostgreSQL also finds a phrase across the end of the title and the start of the body.
• word + symbol + month is the one line PostgreSQL still wins. KDB now lets the cheaper of the text index and the plain index go first; that is not measured yet.

Source: reports/news-search.md (with its addendum), bench/postgres/results/2026-09-23-search-200k-r1.json.

App workload: KDB vs PostgreSQL

Head-to-head. Sign-ups, logins, transfers, forum posts, full-text search and a report join, 20,000 rows, 8 clients.

2026-09-12, PostgreSQL 18.4 native, median of 9 runs:

2026-09-23, PostgreSQL 18.6 in Docker, the build before and after the table-locks merge interleaved in the same minutes (master, merged, master, merged). A sanitizer build and a fuzz test ran on the PC throughout.

• Many writers: table-level write locks and group commit took 8 clients transferring from 604 to 1,981 per second: 3x the build before, 2x PostgreSQL in the same minutes. Balances were conserved in every run.
• Forum search: it lost 17x on 2026-09-12. With LIMIT pushed into the index it went from 7.16 ms to 0.265 ms per search (PostgreSQL 0.843 ms), and wins about 3x now.
• Read with care: PostgreSQL in Docker did far fewer single-client operations than PostgreSQL native on 2026-09-12 (sign-up 123 to 408/s against 943/s). So the single-client lines of 2026-09-23 are left out here; they measure Docker's network as much as PostgreSQL.
• Report join: PostgreSQL is still 3.5x faster. That is the join engine (rows are copied three times on the way out).

Source: reports/benchmark-postgres.md, bench/results/2026-09-12-relational-medians.txt, reports/table-locks-merge.md, bench/postgres/results/2026-09-23-locks-master-r1.json, -r2.json, 2026-09-23-locks-merged-r1.json, -r2.json, reports/news-search.md.

PostgreSQL wire protocol: KDB vs QuestDB

Head-to-head, 2026-09-12. A Go client (pgx v5) over the PostgreSQL port, 50,000 rows, 8 clients, 9 runs. A winner is named only when the paired sign test gives p below 0.05 (8 or 9 wins out of 9).

Eight of nine tests are a tie. A 50,000-row SELECT ran at 66 per second over the PostgreSQL port against 25 over HTTP /exec (KDB against itself, 9 of 9): the PostgreSQL port sends binary, HTTP builds JSON.

Source: reports/benchmark-postgres.md, bench/results/2026-09-12-pgwire-medians.txt.

Indexes, and indexes built at open

Head-to-head, 2026-09-12, 1,000,000 forum posts, one complete run, p50 milliseconds. QuestDB has no full-text index, so it answers with LIKE '%word%'.

The full-text lines of this table are from before the search fixes of 2026-09-23; see news search for today's numbers.

Indexes built at open, KDB-only A/B, 2026-09-23. Indexes live in memory and were built by the first query that needed them after a restart. Now kdb serve builds them on a background thread right after the open. First request after a restart, 200,000 posts, 4 indexes, 9 rounds, cache off:

The open itself did not get slower (274 against 291 ms, ranges overlap). One line got slower by direction only: keyset page 1, 23.0 against 26.4 ms, inside the round-to-round spread.

Source: reports/benchmark-indexes-and-footprint.md, bench/results/2026-09-12-indexes-1m-bench3-full.json, reports/warm-at-open.md, bench/results/2026-09-23-warm-restart-r1.json to -r9.json.

Memory and disk

Head-to-head, 2026-09-12, 1,000,000 minute candles, median of 3 runs. QuestDB's memory is the whole Java server, so only its growth is close to fair.

Source: reports/benchmark-indexes-and-footprint.md, bench/results/2026-09-12-indexes-and-footprint-tables.txt.

Engine changes of 2026-09-23

KDB-only A/B. 1,000,000 rows, one thread, ?cache=0, 7-round medians, before and after on the same build, unless the line says otherwise.

Older engine A/Bs: window frames corr(...) ROWS 199 PRECEDING 9,536 to 431 ms (2026-09-12); count(*), sum(volume) after replaced rows 164 to 44 µs (2026-09-12); the UNION ALL buy-and-sell query 1,750 to 29.2 ms on synthetic data (2026-09-22).

Source: TASKS.md "Done 2026-09-23" and "Done 2026-09-23 evening", reports/zone-maps.md, reports/text-fuzz.md, reports/keyless-runs.md, reports/table-locks-merge.md, reports/window-frame-fast-path.md, reports/column-engine-speed.md, reports/floorsheet-filter-speed.md.

Where the time of one request goes

KDB-only, 2026-09-23 evening, the container on 9900 through Docker Desktop and a native build on Windows loopback, same minutes:

So the socket path is under 2% of a request through Docker and under 15% on loopback. The rest is Docker Desktop's network and the /exec path itself.

Source: TASKS.md, "Re-judged 2026-09-23 evening, measured".

Where KDB is still slower, or not measured

What changed since the list of 2026-09-12: many writers at once (then 1,343 against PostgreSQL's 4,661 transfers/s) and full-text search (then 147 against 2,576 searches/s, and a common-word count 11.8x slower than QuestDB's scan) are now KDB wins. They are not on this list any more.

Source: the files named in the table.