Same PostgreSQL, Same Performance?

Introducing Our Open DBaaS Ranking

Why start with PostgreSQL and a “boring” OLTP workload?

PostgreSQL is a widely adopted open-source relational database with a particularly diverse managed-service ecosystem. The market spans hyperscalers, regional cloud providers, and dedicated PostgreSQL platforms. Our recent blog post identifies more than 30 PostgreSQL DBaaS offerings and the landscape is still evolving.

For the initial database benchmark, we deliberately chose something familiar: the TPC-C implementation of the established BenchBase benchmarking suite. We run it against the SMALL deployment size (see the fairness section for technical details) with provider-default database settings. This establishes a transactional baseline before adding PostgreSQL’s analytical, vector, and other capabilities.

Disclaimer: the presented BenchBase TPC-C results MUST NOT be considered as official, audited TPC-C results.

Same PostgreSQL, different measured performance

As of 15 September 2026, the DBaaS ranking contains 20 entries across 14 PostgreSQL DBaaS offerings, all at SMALL scale. Coverage spans hyperscalers, tier-2 providers including IONOS, OVHcloud, Scaleway, STACKIT and UpCloud, and dedicated platforms such as Aiven, ClickHouse PostgreSqL (beta), Databricks Lakebase and PlanetScale.

The public view includes published results alongside entries with blurred metrics and a Request Access capabilities. The published datasets and methodology are open to scrutiny, and we invite community feedback on provider coverage, workload priorities, and comparison rules.

The three public Intel-based configurations below illustrate the performance difference highlighted in the introduction:

Selected measured configurations: the prices and results shown here refer to the ranking snapshot at the time of writing this article. The live ranking may contain newer measurements. Price-performance is throughput divided by the listed monthly cost, rounded to two decimals; higher is better._

Here, AWS RDS delivers approximately 31% more throughput than Azure and 85% more than GCP, with lower P95 latency. Its listed monthly cost is approximately 11% higher than Azure and 10% higher than GCP. Throughput and price therefore differ by different proportions: similar spending does not imply similar database performance.

The latest Graviton configuration in this snapshot widens the observed gap: AWS RDS db.m9g.2xlarge reaches 4,099 ops/s, approximately 25% above m7i, 63% above the selected Azure configuration, and 130% above GCP. Its P95 latency is 46.5 ms, at a listed monthly cost of $1,482. We keep m7i in the table to compare Intel-based deployments; the Azure and GCP results shown do not include ARM configurations.

These measurements show that a resource comparable DBaaS offer does not imply equivalent performance. TThey do not isolate the effect of provider choice or CPU architecture: processor generations, storage, service architecture, and PostgreSQL minor versions all differ. The figures describe specific configurations under one workload, rather than each provider’s maximum capability. Interpreting the differences therefore requires an explicit definition of what makes these services comparable.

Fairness starts with a definition of comparability

The differences above are meaningful only when their experimental conditions are visible. Without disclosed configurations and workload parameters, benchmark numbers cannot be independently assessed or reproduced. At benchANT, transparency and reproducibility are key concepts of our methodology: we document each experiment and publish the supporting configuration and outputs for publicly released results.

That starts with defining comparability: Equal resources, equal budgets, and equal performance targets answer different questions and cannot generally be satisfied simultaneously.

We begin with resource-equal scaling definitions. The published DBaaS OLTP methodology specifies a vanilla baseline and identifies parameters that can be varied in tuned configurations.

The SMALL PostgreSQL baseline includes:

CPU type remains an explicit comparison dimension; the AWS, Azure, and GCP comparison above deliberately selects Intel-based configurations.

Each measurement records the actual configuration, including deviations required by a provider’s available products.

Matching resource labels cannot remove every difference. 8 vCores do not guarantee identical processing capacity, and 500 GB of SSD storage does not guarantee identical IOPS or bandwidth. Similarly, HA enabled does not establish equivalent replication semantics, failover behavior, and durability guarantees. Provider-default replication is an explicit part of this baseline.

Using provider defaults also defines what is being compared: the service as initially configured under the stated resource constraints. It is worth highlighting, that this does not measure the maximum performance for a specific provider which could be achievable through workload-specific tuning.

Fairness therefore depends on exposing the comparison rules and their limitations. A reader who needs synchronous replication, a particular region, or a different storage class should examine those requirements before comparing throughput values.

Transparency and reproducibility: inspect the experiment

A ranking position alone is insufficient evidence. Readers need to understand how the measurement was produced and whether its conditions match their question.

For publicly released results, we publish infrastructure, database, and workload parameters alongside benchmark outputs on GitHub. For example, this AWS PostgreSQL 17 SMALL dataset includes a BenchBase XML configuration, execution logs, transaction-specific result CSVs, PostgreSQL configuration, resource descriptions, and monitoring artifacts.

Readers can inspect configurations, recompute metrics, investigate bottlenecks using monitoring data, and repeat the disclosed workload without the benchANT orchestration framework.

Reproducibility has a practical boundary in DBaaS. Customers cannot pin every aspect of a provider’s internal infrastructure. Maintenance, service updates, resource placement, and background activity can affect a later run. Repeating the experiment should therefore be understood as testing whether the findings hold under documented conditions, rather than expecting numerically identical results.

If a configuration is unclear, a metric appears inconsistent, or an experimental choice deserves scrutiny, please raise it in the GitHub repository. Public review is part of making the dataset more useful.

What can you learn from the ranking?

The use cases from our earlier database ranking article extend to complete managed-service configurations:

Shortlist services for application-specific testing. Compare measurements for the same workload and scaling size to identify candidates worth evaluating with your own data and access patterns.

Examine database price-performance. Compare measured throughput relative to the stated cost basis. A service with higher throughput can still deliver less throughput per unit of cost. Conversely, the cheapest configuration may be insufficient for the required workload.

Prepare a provider or cloud migration. Use comparable measurements to form hypotheses about performance and cost, then test those hypotheses against your application and operational requirements.

Evaluate versions, tuning, and scaling as coverage expands. Controlled comparisons can help investigate whether upgrades, parameter changes, or larger deployments improve performance sufficiently to justify their costs.

... and what not?

Throughput must be considered alongside latency and concurrency. Our baseline uses 75 terminals (clients) without think time to stress the SMALL deployment. This operating point does not necessarily establish maximum throughput. Small differences require evidence about measurement variability before they support strong conclusions.

Price-performance needs equally careful interpretation. Dividing throughput by a monthly price produces a normalized comparison metric, not a literal count of transactions purchased for one dollar. Check the currency, price date, resource scope, and any usage-dependent charges. An application operating far below the measured throughput can have a different economic outcome.

Finally, a performance ranking does not measure the full value of a managed service. Availability commitments, recovery capabilities, extension support, sovereignty requirements, and operational effort remain separate evaluation dimensions. Production choices require application-specific measurements.

The road ahead

Maintaining this reference means refreshing measurements as services evolve and extending coverage systematically. benchANT will continue publishing the technical context needed to interpret and reproduce results. Planned extensions include:

• More PostgreSQL workloads: vector search, OLAP, NoSQL-like access patterns, and time-series workloads. Each needs explicit semantics and suitable metrics; vector search, for example, requires considering result quality alongside performance.
• Tuned PostgreSQL results: publish workload-specific configurations alongside the vanilla baseline, with changes documented so readers can assess the tuning effort and resulting behavior.
• Larger scaling sizes: increase dataset sizes, concurrency, and instance resources to investigate how throughput, latency, and price-performance change with scale.
• More database systems: extend coverage to services based on MySQL, ClickHouse, MongoDB, and others, using workloads appropriate to their capabilities and intended use cases.
• A combined score across workloads: investigate a summary view while retaining the underlying results. Normalization and weighting must be explicit; a single score otherwise hides which workloads determine the order.

Further extensions include storage comparisons across provisioned IOPS levels and local NVMe options, and repeated runs to expose performance variability. Serverless services would also benefit from scenarios that capture idle periods, cold starts, scaling delays, and usage-dependent billing.

A useful further metric would be cost at a defined service-level objective: for example, the cost of sustaining a target throughput while meeting a specified tail-latency limit. This would complement resource-based comparisons with a question closer to application capacity planning.

Help shape the next iteration

Explore the Open DBaaS Performance Ranking, inspect the data, and tell us what would make it more useful.

Which UI features or comparison views are missing? Which roadmap ideas deserve a thumbs-up—or a thumbs-down? Would another workload, larger deployments, tuned configurations, or additional database systems help you most?

We particularly welcome comments and concerns about fairness, transparency, and reproducibility. If our comparison rules miss an important distinction between services, explain the distinction and how you would test it. You can open a GitHub issue or contact benchANT.

Same PostgreSQL does not mean the same performance or value for money. Explore the data, challenge the methodology, and help shape an open reference for DBaaS performance—continuously maintained and extended by benchANT.