Skip to Content
BenchmarkingOLTP comparison

KalamDB vs TrailBase vs PocketBase

This page publishes a same-machine OLTP bake-off of KalamDB, TrailBase, and PocketBase. The protocol is adapted from TrailBase’s published benchmarks  and trailbase-benchmark : 100,000 inserts, 10,000 timed inserts, then 1,000,000 primary-key point reads, concurrency 16, one authenticated HTTP operation per row.

These numbers are not TrailBase’s AWS/metal figures copied from their site. They are a local re-run on Apple M5 Pro (15 cores, 24 GB RAM) on 2026-08-14. Writes and reads rank differently, so this page does not name a single winner.

Internal KalamDB regression HTML reports live on Benchmarking.

Disclaimer

Benchmarks show how fast the author made a specific setup go, not how fast a system can go in general. This workload is a keyhole: single-row INSERT and primary-key SELECT over HTTP. If your app needs live queries, cold storage, multi-row SQL, or row-level ACLs, these ranks may not apply.

We tried to give each system its primary public API and the same client runtime. If you see a fairness issue, open an issue or PR against the comparison harness . Nothing here replaces measuring your own workload.

What this run used

SystemBinaryPublic path
TrailBase v0.32.1GitHub releaseRecord API POST/GET /api/records/v1/message_api
PocketBase v0.29.3GitHub releaseCollections API POST/GET /api/collections/message/records
KalamDB v0.5.6-rc.0releaseSQL HTTP POST /v1/api/sql

Run order was KalamDB → TrailBase → PocketBase. Treat this as one sample, not a median. Rotate server order before treating the numbers as publishable medians.

[!IMPORTANT] This is not the same API. TrailBase and PocketBase are measured on dedicated record GET/POST routes. KalamDB is measured on general parameterized SQL (POST /v1/api/sql) — the same endpoint a frontend app uses for arbitrary queries, joins, filters, and projections. That extra flexibility has envelope cost. These numbers compare public HTTP paths, not storage engines in isolation.

Insertion benchmarks

Insert wall clock and latency from the 2026-08-14 run. Each group is scaled to its own slowest bar. Lower is better.
  • TrailBase
  • PocketBase
  • KalamDB
4.957 s
15.681 s
6.377 s
100k inserts
0.499 s
1.571 s
0.708 s
10k timed inserts
755 µs
2.015 ms
997 µs
Insert p50
1.122 ms
5.668 ms
1.398 ms
Insert p95
MetricTrailBasePocketBaseKalamDB
100k inserts4.957 s15.681 s6.377 s
10k timed inserts0.499 s1.571 s0.708 s
Insert p50755 µs2.015 ms997 µs
Insert p951.122 ms5.668 ms1.398 ms

TrailBase is fastest on inserts in this run. KalamDB is 28.6% slower than TrailBase on the 100k insert wall clock, and still well ahead of PocketBase.

Read latency

Point-read wall clock and latency from the 2026-08-14 run. Each group is scaled to its own slowest bar. Lower is better.
  • TrailBase
  • PocketBase
  • KalamDB
19.193 s
19.939 s
17.331 s
1M point reads
247 µs
261 µs
251 µs
Read p50
414 µs
536 µs
349 µs
Read p95
MetricTrailBasePocketBaseKalamDB
1M point reads19.193 s19.939 s17.331 s
Read p50247 µs261 µs251 µs
Read p95414 µs536 µs349 µs

KalamDB is fastest on total point-read wall clock in this run (9.7% ahead of TrailBase, 13.1% ahead of PocketBase). TrailBase still has the lowest read p50. KalamDB has the lowest read p95.

This page does not report CPU or RSS for this run.

How to read the comparison

Keep these constraints in view. They are documented because they affect rank, not because they are hidden.

  1. Same machine, concurrency 16, and phase sizes for all three.
  2. Rust HTTP clients for all three, so Dart/Node client floors do not bias one side.
  3. Each system uses its primary public write/read path (Record API, Collections API, or parameterized SQL HTTP).
  4. No multi-row batch inserts. One HTTP create or get per row.
  5. KalamDB is hot-only: the table is created without FLUSH_POLICY, and flush.check_interval_seconds = 0 so the flush scheduler is off.
  6. KalamDB’s comparison server.toml is performance-tuned (larger RocksDB cache and memtables) relative to the tiny low-memory benchv2 defaults.
  7. TrailBase and PocketBase create rules check room_members. KalamDB uses a DBA SQL session and has no equivalent row-level ACL on this path.
  8. Timed point reads consume the response body as bytes and check HTTP status. JSON decoding for setup and generated insert IDs stays outside the timed read comparison.

How to run it yourself

The harness lives in benchv2/comparison in the KalamDB repository.

BASH
git clone https://github.com/kalamdb/KalamDB.gitcd KalamDB/benchv2/comparisonchmod +x scripts/*.sh ./scripts/download-binaries.sh./scripts/run-all.sh # Recommended before treating numbers as mediansCOMPARISON_ORDER="trailbase pocketbase kalamdb" ./scripts/run-all.shCOMPARISON_ORDER="pocketbase kalamdb trailbase" ./scripts/run-all.sh

download-binaries.sh fetches TrailBase v0.32.1, PocketBase v0.29.3, and the tagged KalamDB release asset. This page reports KalamDB v0.5.6-rc.0.

Ports: 2900 (KalamDB), 4000 (TrailBase), 8090 (PocketBase).

Raw logs for this snapshot:

Attribution

Protocol, chat-room schema, and PocketBase migrations are adapted from trailbaseio/trailbase-benchmark . TrailBase’s own write-up is at trailbase.io/reference/benchmarks .

Last updated on
KeycloakRegression reports