Vendor comparisons of database systems are dominated by partial methodologies. Each vendor publishes benchmarks favorable to their own product. Independent comparisons often select workloads that favor one system or another. The result is an information environment where engineering teams cannot easily find balanced analysis.
This benchmark applies systematic methodology across six representative workload types to produce balanced comparison between PostgreSQL 16 and SQL Server 2022. The objective is not to declare a winner but to document where each system performs better and where the differences matter for production decisions.
Methodology
The benchmark uses:
Identical hardware for both systems: 32-core AWS EC2 instance with 256 GB RAM, NVMe-backed storage with 50,000 provisioned IOPS, and 25 Gbps network.
Default vendor configurations as starting point, with documented tuning applied uniformly.
Six workload categories selected to represent common production patterns rather than vendor-specific scenarios.
Three runs per workload with median values reported. Standard deviation reported where it exceeds 5%.
Both systems running the same logical schema where applicable, adapted for vendor-specific syntax.
Workload 1: OLTP transaction processing
Standard TPC-C-derived workload measuring transaction throughput. 1000 concurrent connections with mixed read-write transactions across customer order tables.
PostgreSQL 16: 47,200 transactions/second median throughput, with median latency of 12ms and 99th percentile of 38ms.
SQL Server 2022: 49,800 transactions/second median throughput, with median latency of 11ms and 99th percentile of 41ms.
SQL Server's ~5% throughput advantage in OLTP is consistent with vendor optimization for transaction-heavy workloads. The latency profile is similar.
Workload 2: Analytical queries on warehouse schema
Star-schema workload with fact tables of 500M rows and dimension tables of 1-50M rows. Mixed analytical queries with aggregations, joins, and window functions.
PostgreSQL 16: Average query latency 4.2 seconds, with 99th percentile 28 seconds.
SQL Server 2022: Average query latency 3.1 seconds, with 99th percentile 19 seconds.
SQL Server's columnstore index implementation produces meaningful performance advantage on analytical workloads. PostgreSQL's analytical performance benefits substantially from extension-based columnar storage but the default configuration shows the gap.
Workload 3: JSON-heavy document storage
Workload involving JSONB / JSON document storage and querying. 100M documents with mixed read/write patterns including indexed JSON path queries.
PostgreSQL 16: 89,200 operations/second with median 4ms latency.
SQL Server 2022: 41,800 operations/second with median 9ms latency.
PostgreSQL's JSONB implementation substantially outperforms SQL Server's JSON support. PostgreSQL was designed with JSON support as native; SQL Server's JSON support is layered on a relational core. The performance gap reflects fundamental architectural difference.
Workload 4: Time-series ingestion and querying
Time-series workload with 1M events/second ingestion and concurrent analytical queries on the time-series data.
PostgreSQL 16 (with TimescaleDB extension): Sustained 1.2M events/second ingestion with consistent query latency.
SQL Server 2022: Sustained 0.7M events/second ingestion with degrading query latency under sustained load.
PostgreSQL with TimescaleDB extension shows substantial advantage for time-series workloads. SQL Server's native time-series support is more limited.
Note: Without the TimescaleDB extension, PostgreSQL's time-series performance is comparable to SQL Server. The extension is the differentiator.
Workload 5: Geospatial queries
Workload involving spatial indexes, distance queries, and geospatial joins on map data.
PostgreSQL 16 (with PostGIS): Median spatial query latency 89ms with 99th percentile 380ms.
SQL Server 2022: Median spatial query latency 156ms with 99th percentile 720ms.
PostgreSQL with PostGIS shows substantial geospatial performance advantage. PostGIS is widely considered the most mature spatial database extension available, and the performance characteristics reflect this maturity.
Workload 6: Mixed application workload
Realistic mixed workload combining OLTP transactions, occasional analytical queries, JSON document operations, and infrequent administrative operations. Designed to represent typical production application database usage.
PostgreSQL 16: Average operation latency 18ms with sustained throughput across the mix.
SQL Server 2022: Average operation latency 15ms with similar sustained throughput.
SQL Server's ~17% latency advantage on mixed workload reflects optimization for general OLTP-dominated workloads. The advantage is meaningful but not dramatic.
Summary findings
Across the six workloads, the pattern is:
SQL Server advantages: Pure OLTP throughput (~5%), analytical query latency on traditional warehouse schemas (~25%), mixed workload latency (~17%).
PostgreSQL advantages: JSON document operations (~110% throughput), time-series with TimescaleDB (~70% ingestion), geospatial queries with PostGIS (~75% latency advantage), broader extension ecosystem.
Approximately equivalent: Most fundamental relational operations, simple analytical queries, basic transaction handling.
The choice between systems depends substantially on workload characteristics. Generic recommendations favoring one system regardless of workload are inadequate.
Beyond raw performance
Performance is one input among several for database selection:
Licensing cost. SQL Server has substantial licensing costs in production. PostgreSQL is open source. The cost differential can be substantial for large deployments.
Operational tooling. SQL Server has mature commercial operational tooling including SSMS, comprehensive monitoring, and integration with Windows ecosystem. PostgreSQL has growing operational tooling but with more fragmentation.
Community and support. PostgreSQL has substantial community and broad commercial support. SQL Server has Microsoft commercial support and substantial community.
Cloud integration. SQL Server has deep Azure integration. PostgreSQL has broad cloud support across AWS, GCP, Azure, and others.
Talent availability. Both systems have substantial available talent. Specific markets may favor one or the other.
Historical investment. Organizations with substantial existing investment in either system face migration costs that affect comparative economics.
Recommendations by use case
Based on the benchmark and broader analysis:
For greenfield applications without specific constraints: PostgreSQL. Lower cost, broader extension ecosystem, performance gap for general workloads is small.
For Microsoft-stack organizations: SQL Server. Integration with Azure, .NET, and Microsoft tooling produces operational simplicity that justifies licensing cost.
For document-heavy workloads: PostgreSQL. JSONB performance advantage is substantial.
For time-series workloads: PostgreSQL with TimescaleDB. The combination outperforms SQL Server for this category.
For geospatial workloads: PostgreSQL with PostGIS. The spatial extension is industry-leading.
For pure analytical/data warehouse workloads: Neither is optimal. Specialized analytical databases (Snowflake, ClickHouse, BigQuery) typically outperform both.
For maximum OLTP throughput: SQL Server. The performance advantage is small but consistent.
Implementation considerations
Engineering teams making database decisions should consider:
Total cost of ownership beyond licensing — operational tooling, talent costs, training requirements.
Workload alignment with vendor strengths.
Ecosystem fit with existing technology choices.
Migration risks and costs if switching from existing system.
Long-term vendor strategy and roadmap alignment.
Specific compliance or operational constraints.
Limitations of this benchmark
The benchmark has significant limitations:
Workload selection necessarily simplifies real production patterns.
Default configurations may not reflect optimal production tuning for specific workloads.
Hardware choices affect results in ways that don't generalize across deployment contexts.
Specific extensions and features (TimescaleDB, PostGIS, columnstore) substantially affect results.
Future versions of either system will produce different results than this benchmark.
Conclusions
PostgreSQL and SQL Server are both production-grade database systems with specific strengths. The comparative analysis suggests that workload characteristics should drive selection more than generic vendor preference.
For organizations without specific constraints favoring one system, PostgreSQL's combination of cost advantage, ecosystem breadth, and competitive performance produces strong value.
For organizations with substantial Microsoft integration or specific OLTP performance requirements, SQL Server remains a defensible choice despite higher licensing costs.
The "PostgreSQL vs SQL Server" framing as a single decision is often less useful than considering specific workload requirements and selecting accordingly.
Citation
Kowalski, H. (2024). "PostgreSQL vs SQL Server: Documented Benchmark Across Six Workload Types." PG vs MS Research Report.
