Measured, not promised

Benchmarks

Latency, throughput and memory of a real HorizonDB server on a real PostgreSQL, through the official SDK. Every number on this page comes from the JSON files it links, and every run is reproducible with one command.

Memory

RAM follows what is in use, not what was ever read

A parsed JSON tree costs many times its text. HorizonDB packs documents that went quiet back to compact JSON text, and drops the clean ones nobody touches from memory: PostgreSQL already holds them.

Server RSS after 80 s without traffic

200,000 documents loaded, flushed, then left alone. Lower is better.

Show the data table

Memory per document, by in-memory representation

Same documents, measured with the allocator's own counters. Hot documents use the parsed tree; idle ones the packed text.

Show the data table

Latency and throughput

Tens of microseconds on the hot path

End-to-end through the TypeScript SDK over WebSocket: network, server work and, on cold paths, PostgreSQL. Pipelined scenarios keep hundreds of requests in flight on purpose, so their per-request latency includes queueing.

Request latency per scenario, p50 to p99

Logarithmic scale. The line spans the median to the 99th percentile of each scenario.

Show the data table

Throughput per scenario

Operations per second over the scenario's wall time. Higher is better.

Reproduce

Run them on your machine

Numbers from one laptop are a shape, not a promise: run the suite where you deploy.

Latency suite

Starts PostgreSQL in a container, builds and starts the server, runs every scenario. --json writes the file this page reads.

./scripts/dev-up.sh
bun benchmarks/bench.ts --profile standard \
  --json benchmarks/results/latest.json
  • Scenario catalog and options: BENCHMARKS.md
  • On GitLab CI: the manual bench job runs it against a PostgreSQL service.

Raw results

Everything plotted here, untouched.