Benchmarks

REST, against PostgREST

Requests per second, with median latency. Same request in each server's own dialect.

GraphQL, against Hasura

Postrust and Hasura are sent the same query text, byte for byte.

GraphQL, against PostGraphile

PostGraphile inflects field names its own way, so the query text differs. The request is the same.

How much to trust each number

Repeated whole runs on this host agree to 0.8% for Postrust, 3% for PostGraphile and 3.6% for Hasura. PostgREST is the outlier at 19.6%, so multiples quoted against it carry roughly ±10%. The direction of the differences is far outside that margin; the precise multiples are not, and are not quoted to more precision than they carry.

Running in a container costs about 8.6% against the same binary run natively — 7.3 of those points are Docker's network path rather than the container itself. It is charged to every server equally, so ratios are unaffected and absolute figures are understated by about that much.

Why the REST gap is as large as it is

Worth understanding before quoting the ratio. Three ways it could have been an artefact were tested and ruled out: nothing is cached, and both servers issue exactly one query per request (pg_stat_statements records 3,000 calls for 3,000 requests on each); the connection pools are 10 and 11; and the responses carry the same rows, the same Content-Range and within two bytes of each other.

What differs is the SQL. Postrust sends a plain parameterised SELECT and renders the JSON itself. PostgREST wraps the query in a CTE, computes a count, builds the JSON inside PostgreSQL with json_agg and reads three GUCs — on every request, whether or not a count was asked for or a function set a response header.

So a large part of the ratio is where each design does the work, and PostgREST paying per-request for generality these scenarios do not use. That is a real architectural difference and a fair thing to measure. It is not evidence that Postrust's HTTP layer is four times faster, and the figures should not be read that way.

What stops a bad run being published

Two checks, both of which have caught something real.

The targets must be answering the same question. Every scenario is fetched from every server before any of them is measured. Row counts must match — a difference there is never a dialect difference — and for REST the columns must match too. Until this existed the harness checked an HTTP status and nothing else, so one server returning a single row while another returned twenty-five would have passed and been measured as equal work.

The machine must have held still. The first measurement of a run is repeated as its last action, with everything else in between. If the two disagree by more than 3%, the run exits non-zero and its figures are not publishable. This matters more than it sounds: with a deliberately short 2,000-request window the same comparison reads 13.1x instead of 4.0x, from a run that otherwise looks perfectly healthy. The gate is what stands between that number and this page.

Why those checks exist

This page carried a withdrawn notice for a while, and no numbers at all. The figures that had been here were measured on a virtualised host where the same server, in the same container, measured seconds apart differed by about a factor of two — and whatever ran first was the most understated, which made run order a determinant of the published ratios. Everything below was ruled out at the time, each by direct test, and the mechanism was never identified.

It does not reproduce on bare metal with each component pinned to its own CCD. It was escaped rather than explained, which is exactly why the self-consistency gate is now part of the harness rather than something done by hand — it is what would notice if the effect ever returned. The full record is in scripts/BENCH-FINDINGS.md, and the method in docs/benchmarking.md.