Postgres vs MySQL: 15 FAQs Answered (2026)

Better at different things. Postgres wins for new applications, complex queries, JSONB, GIS, and teams that care about open governance (no Oracle). MySQL wins for read-heavy CRUD on LAMP stacks, WordPress, and sharded OLTP via Vitess (YouTube, Slack, Booking.com). Postgres is the default for greenfield in 2026; MySQL has specific situations where it is still the right answer.

Three reasons: feature depth (JSONB, PostGIS, CTEs, exclusion constraints, multi-language stored procedures), independent governance (PostgreSQL Global Development Group, no Oracle, BSD-style license), and ecosystem velocity (Neon, Supabase, Crunchy Bridge; Heroku, Render, Railway all default Postgres). The Stack Overflow Developer Survey has Postgres as the most admired database since 2022.

Yes. Booking.com, Shopify, Slack, and YouTube run MySQL via Vitess at massive scale. WordPress powers 40%+ of the web on MySQL. MariaDB is a healthy open fork. MySQL 8.4 LTS is supported until April 2032. The LAMP ecosystem is MySQL-native. For these workloads, MySQL or MariaDB is correct. The question is not 'is MySQL alive' but 'is MySQL the right tool for your specific situation'.

Yes. Oracle acquired Sun Microsystems in 2010 and inherited MySQL. Oracle has owned and developed MySQL since then. MySQL is dual-licensed: GPLv2 for open-source use, Oracle commercial license for proprietary use. MySQL HeatWave is Oracle-proprietary and closed-source. PostgreSQL is governed by the PostgreSQL Global Development Group with no single corporate owner. MariaDB is the open-governance fork created by original MySQL founder Monty Widenius.

Oracle's proprietary in-memory query accelerator and ML/AutoML layer for MySQL. Launched 2021. Available on Oracle Cloud Infrastructure (OCI) and AWS (since 2023). Closed-source. Performance claims for OLAP workloads are real in Oracle's benchmarks (vendor-sourced; test your workload). Lock-in: HeatWave-tuned schemas do not trivially migrate away from OCI/AWS. Open alternatives for Postgres: Citus (HTAP), TimescaleDB (time-series), Hydra (columnar).

Days to many months depending on schema complexity, stored procedure surface area, and data volume. pgloader handles small/medium schemas in hours. AWS DMS handles large schemas with CDC over weeks. GitLab's formal MySQL removal took from 2017 to 2020. Heap's Citus migration was multi-quarter. The engineering cost estimate is 4-20 engineering weeks for most medium-scale migrations. The main cost drivers are stored procedure translation, query plan differences, and post-migration stabilisation.

Uber's 2016 engineering blog cited write amplification (index updates), replication architecture preferences, and schemaless layer requirements as the reasons for migrating to MySQL. Critical context: the post predates Postgres 9.6 (parallel queries), Postgres 10 (logical replication, declarative partitioning), and Postgres 12-17 (planner advances). The specific pain points Uber cited have been addressed in subsequent Postgres versions. Many engineers cite Uber's post as a data point that needs version-aware context.

GitLab.com had been Postgres-only since 2016. The 2020 announcement formally removed MySQL as a supported deployment option for self-managed GitLab, citing the maintenance cost of supporting both databases and the desire to invest in Postgres-only features. GitLab's published migration documentation remains available open-source.

Workload-dependent. MySQL InnoDB is slightly faster for simple primary-key point lookups at high concurrency (clustered index advantage). Postgres is faster for complex multi-table joins, analytical queries, and queries that benefit from the planner's strengths. Connection scaling: MySQL has lower per-connection cost than Postgres without pooling; with PgBouncer, Postgres reaches parity. Performance is rarely the deciding factor; both are fast enough for 99% of applications.

Mostly yes since MySQL 8.0. JSON_TABLE, JSON_VALUE, JSON_QUERY, and JSON_CONTAINS closed most of the feature gap. Postgres still leads on ergonomics (-> ->> @> operators are more concise) and GIN indexing (arbitrary JSON path queries at index speed without schema changes). For JSON-heavy workloads with complex queries, Postgres JSONB GIN is a real advantage.

Connection scaling: Postgres forks an OS process per connection; PgBouncer is near-universal in production but adds operational complexity. VACUUM: autovacuum tuning at high update workload requires understanding MVCC bloat. Replication: Patroni/etcd setup for HA has a learning curve (improving in managed services). These are all solvable problems, but real operational costs that MySQL does not have.

Oracle ownership (license risk for some teams, strategic divergence via HeatWave). JSON ergonomics trail Postgres. No RETURNING clause (need LAST_INSERT_ID + SELECT). Fewer extension options (no PostGIS equivalent, no PL/Python). MySQL partitioning requires the partition key in every unique index. Group Replication has documented consistency issues under partition (Jepsen 2023).

Django: Postgres (docs recommend it explicitly; django.contrib.postgres provides JSONB fields, ArrayField). Rails: either works; Postgres slightly more idiomatic for newer Rails features. Laravel: MySQL (ORM, migrations, and ecosystem historically MySQL-tilted). FastAPI/SQLAlchemy: Postgres (Python ecosystem tilts Postgres). Default to the framework's recommendation unless you have a specific reason.

Different sweet spots. Vitess (MySQL) is more battle-tested for sharded OLTP at massive scale: YouTube origin, Slack, GitHub, Booking.com. ~15 years of production at the largest scale. Citus (Postgres) is younger but well-maintained by Microsoft post-acquisition; stronger for HTAP (mixed OLTP and analytics). If your requirement is sharded OLTP at YouTube-scale, Vitess has the deeper track record. For HTAP on Postgres with strong SQL semantics, Citus.

The PostgreSQL License is a BSD-style permissive license. You can use, modify, and distribute PostgreSQL in open or commercial products with minimal restrictions (attribution required, no warranty). It is OSI-approved, FSF-approved, and used by the Linux Foundation as an example of a clear permissive license. There is no GPLv2 copyleft, no Oracle commercial license requirement, and no single corporate owner that could change the terms.