KalamDB Benchmarks & Comparisons
KalamDB is built for fast SQL and realtime application state. This is the home for measured throughput, latency, regression reports, and comparisons with other databases. Every result belongs to a particular workload, version, and machine.
Published KalamDB performance
The existing same-machine comparison with TrailBase and PocketBase measured KalamDB on an Apple M5 Pro with 24 GB RAM and concurrency 16:
| Workload | KalamDB result | How to interpret it |
|---|---|---|
| 1,000,000 HTTP point reads | 17.331 seconds, about 57,700 reads/s | Aggregate throughput, calculated as operations divided by elapsed time |
| 100,000 individual HTTP inserts | 6.377 seconds, about 15,700 inserts/s | One HTTP operation per row; no multi-row batching |
| Point-read p95 | 349 microseconds | Tail latency reported for this particular run |
These are the published August 14, 2026 results for KalamDB v0.5.6-rc.0, not a measurement of the current release. KalamDB had the fastest total point-read time in that run; TrailBase had the fastest insert time. The comparison used different public APIs and authorization paths, including DBA access for KalamDB. Read the full methodology and fairness limits alongside the numbers.
SQL throughput and realtime scaling
Live queries push changes instead of repeatedly polling. Multi-Raft clustering distributes shard leadership and serves subscriptions across nodes. These mechanisms support scalable application workloads, but SQL requests per second, committed writes per second, and subscriber deliveries per second are different measurements.
A realtime result should report subscriber count, fan-out, payload size, filter/RLS shape, initial-snapshot time, change-delivery latency, reconnect behavior, CPU, and memory over the entire run. The HTTP point-read result above does not establish a realtime fan-out limit. Publish a measured realtime report here when that workload has been run.
Benchmark reports
Each row links to a saved HTML artifact. The version and timestamp identify the run; passed/total and duration describe that suite. Duration deltas are meaningful only when the workload, hardware, and configuration are comparable. Open the artifact to inspect individual measurements rather than treating total suite duration as QPS.
Reproduce a comparison
The comparison harness lives in benchv2/comparison in the KalamDB repository:
Follow the complete comparison instructions, including run-order rotation. Record the exact server and harness revisions, data sizes, transport, concurrency, durability, authentication, RLS, storage tier, and hardware. Keep failures and recovery periods in the reported time series.
Publish a new result
For internal benchmark HTML/JSON artifacts, the site has a synchronization command:
Review the resulting artifact changes before publishing: synchronization replaces the site’s benchmark-results directory with that source set. Preserve historical reports in the source directory first. The report table discovers the saved artifacts.
For a new comparison, add a methodology-and-results page under the benchmarking section, link it from this hub, and include raw artifacts and reproduction commands. Publish successes and tradeoffs: repeated runs, median and tail latency, throughput, memory, and errors are more useful than a single fastest number. Do not imply a comparison with PostgreSQL or another database until that system has actually been measured under the stated conditions.
Next step
Read the database comparison →
Reference: Query planning and EXPLAIN.