Postgres has the deeper feature set and the more honest engine. MySQL has the broader ecosystem and the easier replication story. New projects without strong reasons should default to Postgres.
Both are mature, free, and run serious workloads at every scale. They differ in shape, not in capability. Postgres is denser with features and type safety; MySQL is denser with operational lore and library support. The right pick usually comes down to which density a team already lives inside.
Full ACID with serializable isolation via Serializable Snapshot Isolation. The default isolation level is Read Committed; serializable is one setting away. Constraints are enforced at the engine level.
Full ACID on the InnoDB engine, which is the default since 5.5. The older MyISAM engine, still around for legacy schemas, is non-transactional and silently ignores foreign keys. That has eaten production data more than once.
Cost-based and statistics-driven. EXPLAIN ANALYZE produces detailed plans you can trust. The planner handles CTEs, window functions, and recursive queries without manual hints.
Heuristic with some cost-based elements. Multi-table joins sometimes need optimizer hints to produce sensible plans. Improved in 8.0 but still trails Postgres on the harder cases.
WAL streaming for hot standbys, plus logical replication since version 10 for selective table sync. Multi-master needs external tooling like BDR or Citus. Failover is manual unless Patroni or Stolon is wired in.
Native primary-replica via binlog. Group Replication and InnoDB Cluster ship in-box for multi-master and automatic failover. This is the one area where MySQL is operationally simpler.
Custom types, operators, aggregate functions, embedded languages (Python, R, V8), and 250-plus extensions on PGXN, including pgvector, PostGIS, TimescaleDB, Citus, and pg_partman.
Plugin architecture exists, ecosystem is thinner. Storage engines are pluggable (InnoDB, MyISAM, MyRocks, MEMORY) but rarely changed in production. Vector search and similar extensions trail Postgres by years.
JSONB stores parsed binary. GIN indexes on JSONB make property lookups fast. A hybrid relational and document schema can live in one table and one query.
JSON type since 5.7. Storage is text-shaped. Functional indexes work but querying is slower at scale than JSONB. Fine for occasional JSON columns; not for JSON as primary storage.
MVCC with per-row versioning. Long-running readers do not block writers. Vacuum is the trade-off: dead rows accumulate and autovacuum has to manage them. Tuning matters at high write rates.
MVCC on InnoDB with similar guarantees in practice. Undo logs grow instead of dead rows; the purge thread cleans them. Slightly easier steady-state ops for write-heavy workloads.
tsvector and tsquery, with stemmers for 20-plus languages, configurable dictionaries, ranking functions, GIN and GIST indexes. Good enough that apps under roughly 10M documents rarely need a dedicated search engine.
FULLTEXT indexes on InnoDB (5.7+) and MyISAM. Basic English stemmer, limited stop-word configuration, no ranking customisation. Useful as a starter; teams outgrow it.
AWS RDS and Aurora, GCP Cloud SQL, Azure Database, plus specialists like Neon, Supabase, Crunchy, Aiven, and Timescale Cloud. Aurora Postgres uses a different storage layer underneath.
AWS RDS and Aurora, GCP Cloud SQL, Azure Database, PlanetScale (Vitess-based), Aiven. Strong managed-tier presence but fewer specialist providers.
sysbench 1.0.20, 64 client threads, 10M-row table, default tuning, c5.4xlarge (16 vCPU, 64 GB RAM). Numbers approximated from the OnGres "Best practices for benchmarking with sysbench" public study; JSON property lookup added from Crunchy Data's JSONB benchmark.
B2B SaaS with a complex multi-tenant schema
CHECK constraints, custom enums, JSONB for tenant metadata, and row-level security are all native. The schema will use them.
WordPress, Magento, or phpBB at scale
These stacks were built MySQL-first. Every plugin and runbook assumes it. Going against that costs more than it saves.
Financial transactions where correctness comes before performance
Serializable isolation, foreign keys that always work, and a planner that does not silently truncate integers all reduce the surface area for bugs.
High-write IoT ingest at 100K+ rows/s with rolling retention
Both vanilla engines choke on aggressive deletes and partition swaps at this rate. A purpose-built time-series engine is the right shape.
Small team that needs the database to just work
A managed RDS or Cloud SQL instance of either runs for years untouched. The one the team already knows is the right pick.