Benchmarks

Reproduce it

The harness is self-contained: it builds a release binary, starts a throwaway PostgreSQL container, loads 100,000 rows, runs each scenario and prints a table. Everything it created is removed on exit.

git clone https://github.com/postrust/postrust
cd postrust
./scripts/bench.sh

# Heavier load
REQUESTS=20000 CONCURRENCY=100 ./scripts/bench.sh

# Measure a minimal build instead of the shipped feature set
BENCH_FEATURES="" ./scripts/bench.sh

Requires docker, cargo, curl, jq, and either oha or ab as the load generator.

Comparing against other tools

A second harness measures Postrust against PostgREST, Hasura and PostGraphile. Every server runs as a container on one docker network against the same PostgreSQL instance and the same dataset, memory is read the same way for all of them, and each keeps its own default pool and worker settings. Tuning one and not the others measures the tuning rather than the tool.

./scripts/bench-compare.sh

# Alpine base images instead of Debian
VARIANT=alpine ./scripts/bench-compare.sh

# One tool at a time
ONLY=postrust,postgrest ./scripts/bench-compare.sh

Two matrices come out of it, because Hasura and PostGraphile expose no REST surface and PostgREST exposes no GraphQL. Results are written as results.json, and the figures published on the comparison pages are copied from that file rather than retyped.

REST, requests per second

GraphQL, requests per second

PostgREST appears only in the REST table and the two GraphQL engines only in the GraphQL one, because neither exposes the other surface. 3000 requests at concurrency 50, median of 5 runs after 500 warm-up requests, on Darwin 25.2.0 arm64 against postgres:16. Figures from one run are comparable with each other; figures from different runs on a busy machine are not, which is why comparing two versions of the same code means running both side by side rather than one after the other.

Per-tool numbers, including the scenarios where another tool is faster, are on the comparison pages.

Binary size

Size depends on the feature set, so quoting one number without the other is misleading. The published Docker image and release binaries are built with admin-ui, so ~5 MB describes what you actually download.

Measured on macOS arm64, LTO release build, stripped. A Linux x86_64 build differs somewhat.

Throughput and latency

Against a 100,000-row table with indexes on category and price, 3,000 requests per scenario at concurrency 50.

Apple M-series laptop, PostgreSQL 18 in Docker, ab as the load generator, all over loopback.

Memory

Sustained load at concurrency 50 adds a few megabytes over idle and then levels off. Requests that return very large result sets are the exception: fetching all 100,000 rows in one response pushes RSS an order of magnitude higher, and the allocator does not immediately return it. Paginate.

Caveats

Read these before quoting any throughput number, including ours.

Correctness first

A benchmark that measures a broken endpoint is worse than no benchmark, so the harness verifies every scenario returns a success status before timing it, and the query-parameter behaviour it depends on is covered by integration tests against a real database.

DATABASE_URL="postgres://postgres:postgres@localhost:5432/postrust_test" \
  cargo test -p postrust-server --test query_params -- --ignored