PostgreSQL vs MySQL: Syntax Differences, Licensing, Replication and Which to Choose

The short answer

Both are good databases, and the better one is usually the one your applications, tools and team already fit. PostgreSQL is a community project under the permissive PostgreSQL License, with a stricter, closer-to-standard SQL dialect, transactional DDL, jsonb with GIN indexes, and an extension ecosystem. MySQL is owned by Oracle, with a GPL Community Edition, the InnoDB engine, simple and widely known replication, and InnoDB Cluster for built-in high availability. Choose PostgreSQL for new systems with complex queries or rich data types, and as the landing point for an Oracle or SQL Server exit. Choose MySQL when your application, framework or managed service is built around it. Moving a working application between them is a migration, not a setting.

PostgreSQL vs MySQL at a glance

Licensing and governance

PostgreSQL is released under the PostgreSQL License, which the project describes as "a liberal Open Source license, similar to the BSD or MIT licenses". No company owns it. You can embed it, modify it and ship it in a commercial product without releasing your own code.

MySQL Community Edition is free under the GPL. Oracle owns MySQL, decides its direction and sells MySQL Enterprise Edition with extra tools and Oracle support. For most teams that only run MySQL as a server, the GPL makes no practical difference. It matters if you distribute MySQL inside your own product. Our MySQL Enterprise comparison covers Oracle's paid route.

Release and support calendars

The PostgreSQL project supports each major version for five years and then publishes a final minor release. PostgreSQL 14 gets its last community release on 12 November 2026; 18, the current major, is supported to 14 November 2030. MySQL splits releases into LTS series, supported under Oracle's Lifetime Support Policy (8.4 to April 2032, 9.7 to April 2034), and short-lived Innovation releases. Our posts on PostgreSQL major version upgrades and MySQL 8.4 end of life cover the calendars.

PostgreSQL vs MySQL syntax differences

Everyday SELECT, INSERT, UPDATE and DELETE look the same. These are the differences that break a port:

The collation row catches teams more often than any other. A MySQL query that matches 'smith' against 'Smith' returns nothing on PostgreSQL unless you lower-case both sides, use a case-insensitive collation or the citext extension. The DDL row matters for deployment scripts: in PostgreSQL a failed migration inside a transaction rolls back cleanly, while in MySQL each CREATE, ALTER or DROP commits on its own, so a half-applied migration stays half-applied.

JSON

MySQL stores JSON in a binary format with fast access to nested values. JSON columns are not indexed directly; you index a generated column that extracts a value, or use a multi-valued index on an array. PostgreSQL offers json, which keeps the original text, and jsonb, a binary format the PostgreSQL manual recommends for most applications. A GIN index on a jsonb column serves containment queries (@>), key-exists tests and SQL/JSON path queries without naming fields in advance. If documents are central to the design, read our MongoDB vs PostgreSQL comparison too.

Replication and high availability

MySQL ships Group Replication, which runs either single-primary with automatic primary election or multi-primary, and InnoDB Cluster, which wraps it in MySQL Shell. PostgreSQL ships physical streaming replication with read-only hot standbys and logical replication for selected tables. Its manual is explicit that it "does not provide the system software required to identify a failure on the primary". Automatic failover comes from tools such as Patroni or repmgr. Neither approach is weaker; they put the moving parts in different places. See PostgreSQL backup, recovery and high availability for the PostgreSQL side.

Performance

There is no general answer, and published benchmarks rarely transfer to your workload. The engines make different trade-offs. InnoDB stores each table as a clustered index on the primary key, which suits lookups and range scans by key. PostgreSQL keeps tables as heaps with multi-version rows, which needs vacuuming, and offers parallel query, declarative partitioning and a wider choice of index types. Test your own queries, with your own data volumes, on both before letting speed decide.

PostgreSQL vs MySQL vs SQL Server

SQL Server is Microsoft's commercial database. Express edition is free but limited to the lesser of one socket or four cores and 50 GB per database; production use beyond that needs a paid edition, and features such as Always On availability groups are Enterprise-only, with basic availability groups on Standard. Its T-SQL dialect differs from both: TOP (n) or OFFSET ... FETCH instead of LIMIT, square brackets for names, and its own procedural language. Choose SQL Server when you run Microsoft-certified applications or depend on its BI and Windows tooling. When the reason to look elsewhere is licensing or an end-of-support date, PostgreSQL is the usual target, and our SQL Server to PostgreSQL migration guide covers the move. The SQL Server 2017 and 2019 support posts set out the dates.

Which should you choose?

• Choose PostgreSQL for new applications with complex queries, rich data types, geospatial or vector work through extensions, strict data integrity, or a plan to consolidate Oracle and SQL Server estates onto one engine.
• Choose MySQL when your application or framework is written for it, you want InnoDB Cluster built in, your team knows its replication well, or your managed service of choice is MySQL-based.
• Stay where you are when the application works and the only argument is reputation. A port touches schema, queries, collations, stored code and drivers, and needs its own test cycle.

If MariaDB is also on your list, our MariaDB vs MySQL comparison covers how the two have diverged.

Where OSSeva fits

OSSeva supports both engines, so the choice does not have to follow a support contract. OSSeva for PostgreSQL ships patched, signed builds of 11, 12 and 13, and of 14 after its community end of life on 12 November 2026, and supports Patroni and repmgr clusters. OSSeva for MySQL covers 8.4 and 9.7 LTS and ships patched builds of 5.7 and 8.0. Support starts on the community binaries you already run, with no migration first. If you decide to move from SQL Server, OSSeva's SQL Server to PostgreSQL offer runs the migration and supports the result from day one. PostgreSQL and MySQL sit under one contract with MariaDB, Redis, Valkey and Kafka, priced per cluster. Book a discovery call for a quote.

Frequently asked questions

What are the PostgreSQL vs MySQL syntax differences?

The common ones are identifier quoting (double quotes against backticks), case folding of names, IDENTITY against AUTO_INCREMENT, ON CONFLICT against ON DUPLICATE KEY UPDATE, RETURNING (PostgreSQL only), || for concatenation in PostgreSQL against CONCAT() in MySQL, a real boolean type in PostgreSQL, and case-insensitive default collations in MySQL.

PostgreSQL vs MySQL vs SQL Server: how do they compare?

PostgreSQL and MySQL Community Edition are free to run in production; SQL Server needs a paid edition beyond Express's limits. PostgreSQL is community-governed, MySQL is owned by Oracle and SQL Server by Microsoft. SQL Server is the natural fit for Microsoft-centred estates, and PostgreSQL is the common destination when teams leave it.

Which is better, PostgreSQL or MySQL?

Neither in general. PostgreSQL tends to suit complex queries, extensions and strict standards; MySQL suits applications already built around it and teams that want InnoDB Cluster. The cost of switching usually outweighs the difference for a working system.

Is PostgreSQL faster than MySQL?

It depends on the workload, schema and configuration. Benchmark your own queries on both; general claims in either direction do not transfer well.

Is PostgreSQL free for commercial use?

Yes. The PostgreSQL License is a permissive, OSI-approved licence. You can use, modify and distribute PostgreSQL in commercial products without paying a licence fee or publishing your code.

Can PostgreSQL roll back a schema change?

Yes, for most DDL. Wrap CREATE, ALTER and DROP statements in a transaction and a ROLLBACK undoes them. Creating or dropping a database or tablespace is the exception. MySQL commits DDL implicitly.