PostgreSQL vs MySQL

Governance, licensing, 2026 version status, capability and behavior differences between PostgreSQL and MySQL — and when each is the honest choice

PostgreSQL and MySQL are both general-purpose, open-source, client/server relational databases built for transactional workloads — the rare comparison where the two systems genuinely answer the same question. The differences that actually drive a choice are governance, release lifecycle, strictness of SQL semantics, and extensibility, not raw benchmark numbers.

Checked against official sources, 2026-08

Version and support statements on this page follow the official lifecycle pages as of August 2026: PostgreSQL versioning policy, MySQL on endoflife.date (mirroring Oracle's Lifetime Support Policy), and the PostgreSQL beta program. Verify version-specific details before relying on them.

Governance and licensing

	PostgreSQL	MySQL
Steward	PostgreSQL Global Development Group, a distributed community; no single company controls the project	Oracle, which acquired MySQL via Sun Microsystems in 2010
License	PostgreSQL License — permissive, BSD-like	Dual-licensed: GPLv2 Community Edition plus commercial licenses sold by Oracle
Practical consequence	Anyone can build commercial products on it without a license negotiation; forks and derived databases are common (see PostgreSQL-compatible databases)	Embedding MySQL in a distributed proprietary product generally requires Oracle's commercial license; the roadmap is set by one vendor

Neither license restricts normal application use. The difference matters when you redistribute the database itself, or when single-vendor control of the roadmap is a procurement concern.

Version landscape in 2026

The two projects run very different release trains.

MySQL (per endoflife.date/mysql):

Release	Status as of August 2026
8.0	End of life: Premier Support ended April 2025, Extended Support ended April 2026 — no more fixes for community users
8.4 LTS	Supported; Premier to April 2029, Extended to April 2032
9.0–9.6 Innovation	Quarterly feature releases, each supported only until the next one ships; all already ended
9.7 LTS	Released April 2026; Premier Support to April 2034

Oracle's model: Innovation releases arrive roughly quarterly and expire quickly; about every two years one release is designated LTS with 5 years of Premier plus 3 years of Extended Support. Extended Support is a commercial program — a community user on an EOL release gets nothing.

PostgreSQL (per the versioning policy):

Release	Supported until
14	November 12, 2026 (final months)
15	November 2027
16	November 2028
17	November 2029
18	November 2030
19	In beta (Beta 2 as of August 2026); not for production use

One major version per year, each supported for five years, all fixes free. There is no paid tier of the lifecycle: the community release is the only release.

Capability differences

	PostgreSQL	MySQL (InnoDB)
Transactions and isolation	Default READ COMMITTED; REPEATABLE READ and SERIALIZABLE are fully MVCC-based (SSI for serializable)	Default REPEATABLE READ with next-key locks; all four standard levels available
Transactional DDL	Most DDL rolls back with the transaction — schema migrations can be atomic	DDL causes an implicit commit; a failed migration can leave a half-applied schema
JSON	`jsonb` binary storage, rich operators, GIN indexing	Binary `JSON` type since 5.7; indexing via generated columns
CTEs and window functions	Long-standing (recursive CTEs and windows since 8.4, 2009)	Since 8.0 (2018)
Extension ecosystem	In-server extensions adding types, indexes, planners hooks (PostGIS, pgvector, TimescaleDB); see extensions ecosystem	Plugin API centered on storage engines; no comparable mechanism for adding types or index methods
Replication	Built-in physical streaming replication; built-in logical replication since 10	Binlog-based replication (row/statement); Group Replication / InnoDB Cluster for HA
Storage engine	Single engine (heap) with pluggable index access methods; table access methods since 12	Pluggable storage engines; InnoDB is the default and effectively the only transactional one in current use

The table compresses two decades of divergence into rows; none of them is a knockout. The rows that most often decide real projects are transactional DDL, the extension ecosystem, and replication/HA tooling.

Behavioral traps when moving between them

These are the differences that bite during migration, not during selection:

Implicit type conversion. MySQL coerces liberally — 'abc' inserted into an integer column becomes 0 with a warning (or an error only under strict mode); comparing a string column to a number silently converts. PostgreSQL raises an error. Queries that "worked" on MySQL can fail loudly on PostgreSQL, and that is the correct outcome.
Strict mode. Much of MySQL's lenient behavior is governed by sql_mode; STRICT_TRANS_TABLES has been in the default mode since 5.7, but older applications and older defaults silently truncated data and accepted invalid dates like '2024-02-30'. PostgreSQL has no non-strict mode.
Case sensitivity. PostgreSQL folds unquoted identifiers to lowercase and compares strings case-sensitively by default. MySQL's table-name case sensitivity depends on lower_case_table_names and the file system, and its default collations (*_ci) compare strings case-insensitively. Porting an app in either direction exposes assumptions on both sides.
Auto-increment vs identity/sequences. MySQL uses AUTO_INCREMENT columns and LAST_INSERT_ID(). PostgreSQL uses GENERATED ... AS IDENTITY (SQL-standard, since PostgreSQL 10) backed by sequences, and idiomatic code reads the new id via the RETURNING clause rather than a session function.
GROUP BY leniency. MySQL before 5.7 accepted queries selecting non-aggregated columns not in GROUP BY, returning an arbitrary row's value. ONLY_FULL_GROUP_BY has been on by default since MySQL 5.7, so current MySQL and PostgreSQL agree — but legacy code written against the lenient behavior still surfaces during migrations.

When to choose which

Honest reasons to choose MySQL:

The application ecosystem dictates it. WordPress, most LAMP-era PHP applications, and many commercial products are tested only against MySQL/MariaDB. Running them on PostgreSQL means owning the compatibility risk yourself.
Team experience. A team with ten years of MySQL operational scar tissue will run MySQL more safely than a database it does not know. This is a legitimate, often decisive, reason.
Platform availability. Shared hosting, cPanel-style platforms, and some managed services offer MySQL/MariaDB and nothing else.
Specific tooling. InnoDB Cluster / MySQL Shell administration, or a commercial support relationship with Oracle, can be requirements in their own right.

Honest reasons to choose PostgreSQL:

Complex SQL and strict integrity. Transactional DDL for safe migrations, strict typing, richer constraint and isolation semantics — see transactions.
Document, geospatial, or vector workloads on one engine: jsonb, PostGIS, pgvector.
Extensibility. Custom types, operators, index methods, and an extension ecosystem MySQL has no equivalent of.
Governance independence. No single vendor sets the roadmap or holds a commercial license over your head.

Performance benchmarks are rarely the honest deciding factor between these two; operational fit usually is.

Migration pointers

Migrating from MySQL to PostgreSQL is mostly a semantics port, not a data copy: pgloader moves schema and data, but the behavior differences above (type coercion, case, GROUP BY, auto-increment) are what need testing. For adjacent decisions, see the Oracle to PostgreSQL guide if Oracle is also in the picture, and the comparison FAQ for short answers to recurring selection questions.

PostgreSQL vs MariaDB — the other MySQL-lineage comparison
PostgreSQL lineage and compatible databases — systems that reuse PostgreSQL itself
Transactions — the isolation and DDL semantics referenced above
PostgreSQL version policy — the support lifecycle in more detail