Skip to content
Innovation & Growth

Supabase-sponsored DBArena invites buyers to rerun Postgres benchmarks

The method is open and the limits are listed. No one outside Supabase has yet confirmed the results.

W
WebPulse Newsroom
AI-assisted · 5 min read
Share on X LinkedIn
Supabase-sponsored DBArena invites buyers to rerun Postgres benchmarks
In brief
  • Supabase, which sponsors DBArena, published open hosted Postgres benchmarks covering its own service, Amazon RDS and Google Cloud SQL, with a raw data file for each result.
  • Supabase says the results can be rerun, but no outside party has confirmed that yet. It also lists limits: one workload, one region per cloud, list prices and no think time.
  • Before using any benchmark in a buying decision, rerun it on your own workload and check who paid for it.

A benchmark you can rerun asks for less trust

Database speed claims usually arrive as a single number from the company selling the product. DBArena, a site Supabase announced on October 30, tries a different offer. It publishes the commands and settings behind each result so that others can repeat the test. It covers hosted Postgres, the open-source database that many companies rent from a cloud provider instead of running themselves.

Supabase's own critique of the field is blunt. It argues that published database benchmarks mostly come from vendors, which makes them awkward to set side by side. It names mismatched machine sizes, tuned settings for one product against defaults for another, and results that others struggle to repeat. It adds that many ignore cost.

That is a vendor describing its competitors. Treat it as Supabase's view. The useful idea inside it is this: a number you cannot reproduce asks for your trust, while one you can reproduce asks for your time. Supabase says DBArena is the second kind. Nobody outside the company has yet reported rerunning it, so that remains a claim.

What was measured, and how

The first round tests four setups. Two are Supabase Postgres, one with its standard storage and one with an alternative engine called OrioleDB. The others are Amazon RDS and Google Cloud SQL in its Enterprise edition. Each is tried at up to seven sizes, from 2 virtual CPUs and 2 GiB of memory up to 32 virtual CPUs and 128 GiB.

All tests use Postgres 17 with each provider's default settings. Clients connect directly over an encrypted link, with no connection pooler in between.

The test load is adapted from TPC-C, an industry-standard exercise that simulates a business taking and filling orders. Supabase says it switched off think time, the pause a real user takes between actions. Without pauses, the test finds the most work a database can handle, not how a typical application behaves. Supabase also states that its version does not meet all TPC-C requirements, so it cannot be compared with official TPC-C results.

For each test, Supabase says it builds a fresh database, discards a 30-minute warmup, then measures for 60 minutes. It repeats until three runs succeed and publishes the median. The first round ran from September 25 to October 1, 2026. It produced 62 published results from more than 750 runs.

Why memory and disk decide the outcome

Supabase tests two data sizes. In the first, the whole data set fits in memory, so the database rarely touches disk. Speed then depends mostly on processor power. In the second, the data is four times larger than the available memory. Now the database must keep fetching data from disk, and disk speed becomes the limit.

This is why the sizing rule matters. Supabase matches products by CPU count, not by memory. A provider that gives more memory per CPU can keep more data close to the processor. At some sizes that gives it an edge, especially in the larger-than-memory case. Supabase lists this as a limit. For a buyer, it means two services with the same CPU count may not be equal rivals.

Supabase says it matches disk speed and throughput across providers for the larger-than-memory test. That narrows the gap, but the memory difference remains.

Price sits beside speed

Each test point yields three figures: average transactions per minute, that rate divided by monthly cost, and p95 latency. The last is the time within which 19 out of 20 transactions finish.

The cost ratio is the one a finance team will watch. A faster service that costs more can score lower on it. Supabase says the prices are public on-demand rates with no discounts. A company paying a negotiated rate would see a different ratio.

Read the limits before the scores

Supabase sponsors DBArena, and its own service is among the products tested. Its load generator, go-tpc, is a Supabase fork of an upstream project. None of this proves bias. It does mean the results are a vendor's claim until someone else reruns them.

To its credit, Supabase lists its limits. Everything rests on one workload. Tests ran only in one AWS region (us-east-1) and one Google Cloud region (us-east1). Other regions, delays between regions and read replicas are outside the test.

Placement also differs. For Amazon RDS and Google Cloud SQL, the load generator sits in the same availability zone, meaning the same data centre, as the database. Supabase does not offer zone selection, so its generator is only in the same region. Supabase lists this as a difference, though the announcement does not say how much it affects results.

This announcement does not include the scores themselves, so this article does not report who came out ahead.

What to ask your team

Treat DBArena as a way to test claims, not a verdict. Ask your engineers four things.

First, does our workload look like constant order processing with no pauses? Second, does our data fit in memory, or will it exceed it? Third, do we run in one of the two tested regions, and what do we pay compared with list price? Fourth, can we rerun one test point?

Supabase says each result ships with a result.json file recording the configuration, price, software versions and exact command. It also says adding --dry-run to the first command previews what will be provisioned without creating anything.

The practical test of this benchmark is whether someone other than its sponsor can repeat it and get similar numbers. Until then, use it to sharpen your questions, not to settle them.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Supabase.