What size fits your app?
Pick an appropriate size
01.0 / 2 vCPU · 2–4 GiB
Side project
Supabase Postgres wins on tpm/$ at Small, Google Cloud SQL for PostgreSQL at Medium.
At Small (2 vCPU · 2 GiB), Supabase Postgres achieves 10% more peak throughput per dollar than Supabase OrioleDB.
Small · 2 vCPU · 2 GiB tpm/$ · higher is better
- 1Supabase Postgres426$41.50/mo
- 2Supabase OrioleDB388$41.50/mo
- 3Amazon RDS163$113.26/mo
- —Google Cloud SQL for PostgreSQLNot measured
transactions/min per dollar of monthly list price.
02.0 / 2–8 vCPU · 8–32 GiB
Production
Amazon RDS wins on tpm/$ at Large–2XLarge.
- 1Amazon RDS299$135.89/mo
- 2Google Cloud SQL for PostgreSQL194$174.68/mo
- 3Supabase OrioleDB155$136.50/mo
- 4Supabase Postgres137$136.50/mo
| Product Value · tpm/$ | Large2 vCPU · 8 GiB | XLarge4 vCPU · 16 GiB | 2XLarge8 vCPU · 32 GiB | Instance |
|---|---|---|---|---|
| Amazon RDS | 299$135.89/mo | 173$269.94/mo | 251$580.36/mo | db.m9g.large |
| Google Cloud SQL for PostgreSQL | 194$174.68/mo | 100$276.32/mo | 94$676.07/mo | db-custom-N4-2-8192 |
| Supabase OrioleDB | 155$136.50/mo | 172$237.00/mo | 119$674.63/mo | large |
| Supabase Postgres | 137$136.50/mo | 160$237.00/mo | 102$674.63/mo | large |
transactions/min per dollar of monthly list price.
At Large (2 vCPU · 8 GiB), Amazon RDS achieves 54% more peak throughput per dollar than Google Cloud SQL for PostgreSQL.
03.0 / 16–32 vCPU · 64–128 GiB
Heavy load
Amazon RDS wins on tpm/$ at 4XLarge, Supabase OrioleDB at 8XLarge.
At 4XLarge (16 vCPU · 64 GiB), Amazon RDS achieves 9% more peak throughput per dollar than Supabase OrioleDB.
8XLarge · 32 vCPU · 128 GiB tpm/$ · higher is better
- 1Supabase OrioleDB139$2,177.63/mo
- 2Supabase Postgres108$2,177.63/mo
- 3Google Cloud SQL for PostgreSQL83$1,928.29/mo
- 4Amazon RDS71$2,184.90/mo
transactions/min per dollar of monthly list price.
04.0 / All seven sizes, cache exceed
When your data set grows
The benchmark data set is four times larger than available RAM, so reads need to be served by the disk.
At Small (2 vCPU · 2 GiB), Supabase OrioleDB achieves 47% more peak throughput per dollar than Supabase Postgres.
Small · 2 vCPU · 2 GiB tpm/$ · higher is better
- 1Supabase OrioleDB155$41.50/mo
- 2Supabase Postgres106$41.50/mo
- 3Amazon RDS25$113.26/mo
- —Google Cloud SQL for PostgreSQLNot measured
transactions/min per dollar of monthly list price.
Small through 8XLarge · transactions/min
At a glance
Key metrics at every size.
| Product | $/mo | tpm | tpm/$ | p95 | Clients | Instance | Measured |
|---|---|---|---|---|---|---|---|
| Amazon RDS | $135.89 | 40,583 | 299 | 18 ms | 12 | db.m9g.large | |
| Google Cloud SQL for PostgreSQL | $174.68 | 33,826 | 194 | 24 ms | 12 | db-custom-N4-2-8192 | |
| Supabase OrioleDB | $136.50 | 21,182 | 155 | 28 ms | 12 | large | |
| Supabase Postgres | $136.50 | 18,705 | 137 | 32 ms | 12 | large |
All prices are list prices. A month equals 730 hours.
Amazon RDS40,583
transactions/min · Large · Amazon RDS
Raw results
- $ open aws/rds/tpcc/cache-fit-large/result.json
- $ open gcp/cloud-sql-for-postgres/tpcc/cache-fit-large/result.json
- $ open supabase/orioledb/tpcc/cache-fit-large/result.json
- $ open supabase/supabase/tpcc/cache-fit-large/result.json
Each file contains the results we show on this website and additional metadata to aid reproduction of our results, such as specific commands and software versions used.
Behind the results
Why and how we built these benchmarks
Selecting a suitable provider to host your database involves many factors, such performance or cost. We built these benchmarks to compare alternatives based on the resource requirements of your business.
There are plenty of database benchmarks on the Internet but they usually suffer from one or more flaws. Read on to see how our approach differs:
- Results are not fully reproducible and the setup is open to interpretation.
- Apart from the measurement results, we provide a rich set of metadata with every test point, e.g. software versions, machine specs or system metrics of the load generator. Every step from instance setup to results generation is automated, so every aspect of the setup can be reproduced, scrutinized and improved.
- Only one data point is measured, e.g. a certain compute size.
- We benchmark several common sizes across two different scenarios (data volume fits in cache, data volume exceeds the cache).
- Only absolute performance is compared.
- While we strive to match hardware as closely as possible, there is no perfect hardware match across providers. Therefore, we provide two comparison options: absolute performance and price-performance. The latter allows to gauge which provider provides the best value once performance requirements are met.
Our methodology in four steps
- More details
01Match
We match each product based on vCPU count.
- More details
02Load
We benchmark two scenarios: either the data set fits in RAM (cache-fit) or exceeds it (cache-exceeding).
- More details
03Run
We repeat each benchmark run three times.
- More details
04Publish
Every result is published with a rich set of metadata to aid reproduction.
Limitations
So far we use only a single workload derived from TPC-C. Other workloads will stress systems differently and we plan to expand our workloads to provide a more nuanced picture. See the methodology page for more info.