How to Choose a Managed Postgres Provider in 2026, and How to Read the New Vendor Benchmarks

If you are deciding how to choose a managed Postgres provider for a new product, October gave you more data than usual. Supabase launched DBArena, a public benchmark site for hosted Postgres, and ClickHouse has been publishing PostgresBench since April. Both are open and reproducible. Both are also run by companies that sell Postgres. This guide explains what to check before performance matters, how to read these benchmarks without being steered by them, and how to run a small test of your own that settles the decision for your workload.

Why this question came back in October 2026

Two things changed the conversation. First, Supabase introduced DBArena, with results published on October 2, 2026. Its first round compares Supabase Postgres on default heap storage, Supabase with the OrioleDB storage engine (in beta), Amazon RDS for PostgreSQL, and Google Cloud SQL Enterprise edition, across up to seven compute sizes. It reports transactions per minute, transactions per minute per dollar of monthly cost, and p95 latency.

Second, it joins ClickHouse's PostgresBench, which compares Postgres managed by ClickHouse with Aurora, RDS, Neon, and Crunchy Bridge using pgbench.

That is good news for buyers. A year ago, most "best Postgres host" pages were opinion. Now there are public methods you can inspect and rerun. The catch is that a benchmark answers the question its author chose, and the author is a competitor in the results.

Step one: rule providers out before you compare speed

Most provider decisions are made by requirements, not throughput. Before you open a benchmark, write down the things that would disqualify a provider outright.

• •Regions and data residency. If you sell to UK or EU customers who expect their data to stay in Europe, under UK GDPR or GDPR, the provider needs a region there for your primary database and your backups.
• •Extensions. List every extension you use or plan to use, such as pgvector for AI search or PostGIS for maps. Check the provider's supported list and version, not just the name.
• •Postgres major version and upgrades. Know which versions are offered and how major upgrades work. Our post on PostgreSQL 14 end of life shows what happens when an upgrade is left too late.
• •Backups and point-in-time recovery. Check retention, how restores work, and how long they take.
• •Private networking and compliance. If you are working toward SOC 2 or handling health data under HIPAA, you may need the database inside your own cloud network and a signed agreement from the provider.
• •Connection limits and pooling. Serverless functions open many short connections. Confirm a pooler is available and whether your code relies on session features that break under transaction pooling.
• •An export path. You should be able to take a full logical dump and leave. If you cannot, that is a lock-in decision, made silently.

A provider that fails one of these is out, however fast it is.

Step two: pick an operating model

The remaining providers fall into three groups, and the group matters more than the brand.

Hyperscaler Postgres (Amazon RDS or Aurora, Google Cloud SQL, Azure Database for PostgreSQL) fits teams that already run on that cloud and want the database inside the same account, network, and billing. You get the most control and the most configuration work.

Backend platforms (Supabase is the best-known example) bundle Postgres with auth, file storage, and auto-generated APIs. For an MVP, that can remove weeks of plumbing. The trade-off is that more of your app depends on one vendor's services, not just its database.

Serverless Postgres (Neon is the common example) separates storage from compute, so databases can scale down when idle and you can branch a copy for each pull request. That suits preview environments and spiky traffic.

Our default for a new SaaS is plain Postgres with as little vendor-specific surface as possible, whichever host it runs on. We explain the wider reasoning in the stack we use for SaaS.

How to read a vendor benchmark

Once you have two or three candidates, benchmarks become useful. Read the methodology before the chart.

Here is what to look for, using the two current benchmarks as examples.

• •Who ran it. Supabase sponsors DBArena. ClickHouse wrote PostgresBench, and its own post concedes that no benchmark is perfectly neutral. Neither fact makes the data wrong, but it tells you which question was likely asked first.
• •The workload. DBArena uses a workload derived from TPC-C with think time disabled, so it measures maximum throughput rather than a normal app with idle gaps. PostgresBench uses pgbench's TPC-B-like workload: short transactions with frequent writes. Your app is probably neither.
• •Whether data fits in memory. DBArena runs a "cache fit" scenario and a "cache exceeding" one, where the data set is four times larger than RAM. Its headline result, that OrioleDB had the highest throughput per dollar at every size, is from the cache-exceeding case, on a storage engine that is still in beta.
• •How sizes are matched. DBArena matches by vCPU count, which can favor providers that give more RAM per vCPU. In PostgresBench, Aurora ran with twice the RAM per vCPU of the other services because it lacks a matching instance class, and storage was not identical across services.
• •Price and topology. DBArena uses on-demand list prices with no discounts and tests one region per cloud, with no replicas. PostgresBench did not compare pricing at all and disabled high availability everywhere. Your production bill will include replicas, backups, and probably a commitment discount.

So use the benchmarks to narrow a shortlist and to learn what to test. Do not use them to make the final call.

Run a one-hour test of your own

The only result that decides anything is your schema and your queries on your finalists. This is a half-day of work, not a project.

Restore a copy of your schema with realistic data volume onto each finalist, in the region you will use. Then replay your most common queries. The pgbench documentation covers custom scripts, which let you run your own SQL instead of the built-in test:

# app.sql holds 3 to 5 of your hottest queries, using \set for random ids
pgbench "$DATABASE_URL" \
  --file=app.sql \
  --client=32 --jobs=8 \
  --time=3600 \
  --protocol=prepared \
  --progress=60 \
  --report-per-command

Borrow the good parts of the public benchmarks: discard a warmup period, run for at least an hour, repeat each run, and compare medians. Set --client to the concurrency you expect at launch, not the maximum the database can take. Look at p95 latency per query, because one slow query on a key page matters more than average throughput.

Then price what you tested. Add replicas, backup retention, and data transfer, and compare the monthly totals for the setup you would actually run.

Plan the exit before you launch

Every provider looks permanent until pricing, a region, or a feature changes. The cheapest insurance is to rehearse leaving once, before you have customers.

We learned the value of that on the America Working platform, where we moved more than 240,000 records from drifting spreadsheets into a single Postgres schema. The first migration run took six hours and corrupted about 300 rows because of an encoding mismatch. We added a quarantine table, made the job idempotent, and re-ran it in 90 minutes with zero data loss. A rehearsal is where you want to find that problem, not a cutover night.

Keep the rehearsal simple: take a full dump, restore it on a second provider, check row counts and a few key queries, and write down how long it took. Keeping billing and other critical data in your own tables, as we describe in syncing Stripe data to Postgres, also makes the database easier to move.

If you are building the product as well as choosing its infrastructure, our SaaS development service covers database design, hosting choice, and the migration plan as part of the build.

Conclusion

Choosing a managed Postgres provider is mostly a requirements exercise. Rule out anything that fails your regions, extensions, recovery, and compliance needs. Pick the operating model that fits your team. Then use DBArena, PostgresBench, and whatever comes next to build a shortlist, and let a one-hour test on your own workload make the final decision. Rehearse the exit before launch, and the choice stays reversible.

If you would like a second opinion on your database setup or a plan for a new product, tell us about your project.