SQL Server 2025 vs PostgreSQL 17 on 2 vCPU: What This Benchmark Shows
A HammerDB test found a large apparent gap. See the PostgreSQL tuning, measurement mismatch, and requirements for a fair rerun.
29 Sept 2026 · 4 min read
A HammerDB test on two identically sized 2 vCPU, 4 GB Ubuntu hosts produced a large apparent throughput gap between SQL Server 2025 and PostgreSQL 17. The PostgreSQL run reported 8,937 NOPM and 20,495 TPM. A separate SQL Server DMV capture peaked near 2,158 transactions per second.
Those figures are useful, but they do not support a clean "SQL Server is 6x faster" conclusion. The two sides were measured with different counters and different test windows. This article documents the result, the PostgreSQL tuning used, and the changes needed for a defensible rematch.
Test environment
Both database hosts used the same headline capacity:
2 vCPU cores
4 GB RAM
SSD storage
Ubuntu 24.04 LTS
50 TPC-C warehouses
50 HammerDB virtual users
The PostgreSQL timed run used a 10-minute ramp-up and a 5-minute measurement window. The SQL Server metrics were collected for 10 minutes through SQL Server dynamic management views (DMVs).
HammerDB's TPC-C workload simulates order processing across warehouses. New-Order transactions account for about 45 percent of the mix, Payments about 43 percent, with Order-Status, Delivery, and Stock-Level making up the balance.
PostgreSQL 17 tuning used in the test
The tuned PostgreSQL run changed these server settings for the constrained host:
`shared_buffers = 1GB`
`effective_cache_size = 3GB`
`synchronous_commit = off`
`checkpoint_timeout = 15min`
`checkpoint_completion_target = 0.9`
`random_page_cost = 1.1`
`effective_io_concurrency = 200`
`huge_pages = try`
`max_connections = 100`
`wal_level = minimal`
Autovacuum remained enabled. This matters for TPC-C because updates create dead row versions in hot tables such as STOCK, CUSTOMER, DISTRICT, and ORDER_LINE.
Two settings change the production meaning of the result. `synchronous_commit = off` can lose recent acknowledged transactions after an operating-system or power failure. `wal_level = minimal` disables the WAL information needed for physical replication and continuous archiving. They are reasonable benchmark choices only when those durability and recovery limits are stated clearly.
Reported PostgreSQL result
HammerDB printed:
`System achieved 8937 NOPM from 20495 PostgreSQL TPM`
NOPM, or New Orders Per Minute, is the main HammerDB TPC-C metric. It counts the New-Order business transaction and is designed for cross-engine comparison when both engines run the same driver configuration.
The 20,495 TPM figure converts to about 342 transactions per second. That is the average represented by the final TPM counter, not a separate peak measurement. The report also cites an average near 189 TPS from sampled data, so the raw time series and calculation method should accompany any final comparison.
Reported SQL Server result
The SQL Server side used a stored procedure to sample DMV performance counters. Across 214 samples, the capture reported a peak near 2,158 TPS and an average near 883 TPS.
This is where the comparison becomes uncertain. A SQL Server DMV counter such as Batch Requests/sec is not automatically equivalent to HammerDB NOPM, TPM, or completed TPC-C transactions. One business transaction can execute several SQL batches. Internal activity and the exact counter selected also affect interpretation.
The SQL Server numbers show that the server processed a high rate of measured activity. They do not, by themselves, prove a sixfold TPC-C advantage over PostgreSQL.
Why the apparent gap may be large
Several technical factors can affect PostgreSQL on a two-core host:
PostgreSQL uses one backend process per client connection. Fifty active clients plus WAL, checkpoint, autovacuum, and background processes compete for two CPUs.
A write-heavy workload puts pressure on WAL generation, buffer eviction, and checkpoints.
MVCC creates dead tuples that autovacuum must reclaim while the benchmark is running.
A 1 GB shared buffer pool cannot hold a roughly 5 GB dataset, so storage and operating-system cache behavior matter.
SQL Server has a different execution and memory architecture, including an integrated buffer pool, background write activity, and group commit behavior. Those differences may help on constrained hardware. They still need to be tested with the same business-level output metric before they can explain a measured winner.
Four issues to fix before declaring a winner
Use HammerDB NOPM and TPM for both engines. Do not compare PostgreSQL TPM with a SQL Server DMV batch counter.
Use the same ramp-up and measurement duration. Keep the warehouse count, virtual users, driver mode, and think-time settings identical.
Match durability. Compare PostgreSQL `synchronous_commit` with the corresponding SQL Server durability behavior, and report storage-cache settings.
Publish the raw run artifacts. Include HammerDB logs, counter definitions, latency percentiles, CPU, memory, disk latency, database size, and configuration files.
A useful follow-up would test 10, 25, and 50 virtual users. Fifty database processes on two CPUs may measure connection contention more than engine throughput. A second PostgreSQL run through PgBouncer would show how much of the result comes from the process-per-connection model.
PostgreSQL 18 follow-up
PostgreSQL 18 added an asynchronous I/O subsystem for reads and some maintenance work. It does not remove the WAL write path that dominates a write-heavy TPC-C run, but faster reads and vacuum work may reduce pressure elsewhere. Repeating the test on PostgreSQL 18 with the same business-level metrics would make the next comparison more useful.
The practical conclusion
This benchmark found 8,937 PostgreSQL NOPM on a small host and a much larger SQL Server DMV rate. It also exposed the main lesson of database benchmarking: identical hardware is not enough. The workload, durability policy, time window, and metric definition must match.
Treat the current result as a strong reason to rerun the test, not as a final engine ranking. The next run should report NOPM, total TPM, latency, and resource saturation from both systems under one HammerDB procedure.
Plan a database benchmark or migration with Worlber
Worlber helps teams benchmark PostgreSQL and SQL Server with matched workloads, production-safe durability settings, raw evidence, and repeatable runbooks. We can also assess PostgreSQL migration options, tune constrained environments, and design the production platform around your recovery and availability requirements.