Compare PostgreSQL, MySQL, and SQL Server — what are the meaningful differences?
Quick Answer
**PostgreSQL** is open-source, standards-compliant, and known for its extensibility (custom types, extensions like PostGIS/pgvector) and advanced features (transactional DDL, sophisticated indexing options). **MySQL** is open-source, historically simpler and very widely deployed (especially in web/LAMP-stack contexts), with InnoDB as its default storage engine. **SQL Server** is Microsoft's commercial offering, deeply integrated with the Windows/.NET ecosystem and enterprise tooling, with strong built-in BI/reporting/analytics features. All three are mature, fully capable relational databases for the vast majority of workloads — the differences that matter most in practice are ecosystem fit, licensing cost, and specific advanced features, not raw core SQL capability.
Detailed Answer
PostgreSQL
- Licensing: fully open-source (PostgreSQL License, a permissive license), no per-core/per-instance licensing cost.
- Standards compliance and features: widely regarded as closely following the SQL standard, with advanced capabilities like transactional DDL (schema changes can be rolled back — see the DDL/DML question), rich indexing options (GiST, GIN, BRIN, partial and expression indexes), native JSON/JSONB support with indexing, and a strong extension ecosystem (PostGIS for geospatial data, pgvector for vector similarity search, TimescaleDB for time-series).
- Concurrency model: MVCC (see that question), generally praised for read-heavy workload performance and its handling of complex queries.
- Where it's chosen: teams wanting maximum standards compliance, extensibility, and avoiding licensing costs; increasingly the default choice for new greenfield projects across many industries, including where advanced data types (geospatial, vector embeddings for AI workloads) matter.
MySQL
- Licensing: open-source (GPL), with a commercial/enterprise edition (MySQL Enterprise) offering additional support and features; owned by Oracle.
- History and ecosystem: extremely widely deployed, historically the "M" in the LAMP stack, with enormous community familiarity, hosting-provider support, and tooling maturity for typical web application workloads.
- Storage engines: pluggable storage engine architecture, with InnoDB (ACID-compliant, row-level locking, the modern default) as the standard choice; the older MyISAM engine (table-level locking, no transactions) still exists but is rarely the right choice for new work.
- Where it's chosen: teams prioritizing broad ecosystem familiarity/tooling, particularly common in traditional web application stacks (WordPress, many PHP/web frameworks default to MySQL-compatible databases).
SQL Server
- Licensing: commercial, with per-core or per-server licensing costs (a free Express edition exists with resource limits); owned by Microsoft.
- Ecosystem integration: deep integration with the Windows Server and .NET ecosystems, Active Directory authentication, and Microsoft's broader enterprise/BI tooling (SQL Server Reporting Services, SQL Server Integration Services, Power BI).
- Tooling: SQL Server Management Studio (SSMS) is a mature, widely-used GUI management tool; strong built-in support for complex analytical/BI workloads out of the box.
- Where it's chosen: organizations already standardized on Microsoft/.NET infrastructure, or with existing enterprise licensing agreements and BI tooling investments that make the ecosystem fit decisive.
What's mostly similar across all three
Core relational SQL capability — joins, transactions, indexing fundamentals, window functions (all three now support them), stored procedures — is broadly comparable across all three for the overwhelming majority of application workloads. The meaningful differentiators for a real decision are usually: licensing cost model, existing team/organizational familiarity, specific advanced feature needs (PostgreSQL's extensibility, SQL Server's BI integration), and hosting/cloud-provider ecosystem fit — not "which one is fundamentally more capable at SQL," since that gap has narrowed significantly over the past decade.