Every few years someone declares this debate over, and every few years it isn't, because both databases keep shipping and both keep running an enormous share of the internet. The honest 2026 answer is that PostgreSQL and MySQL are both excellent, both fast, and both capable of backing almost any web application you're likely to build. The differences that remain are real, though — they're just narrower and more specific than the flame wars suggest. Here's where they actually are.
The state of each project
PostgreSQL ships a major release every autumn, and the recent ones (16, 17, 18) have focused on performance: better parallelism, faster vacuuming, smarter query planning, improved logical replication. The extension ecosystem is the headline story of the last few years — pgvector alone pulled a wave of AI workloads onto Postgres, and PostGIS remains the default answer for geospatial. The [official docs](https://www.postgresql.org/docs/current/) are among the best in open source.
MySQL moved to an LTS model: 8.0 is the long-serving workhorse, 8.4 is the current LTS line, and the 9.x "innovation" releases iterate faster for those who want them. InnoDB is a genuinely great storage engine, group replication and MySQL Shell have matured, and the [reference manual](https://dev.mysql.com/doc/refman/8.4/en/) covers it all. The elephant-adjacent fact worth knowing: a lot of "MySQL" in the wild is actually deployed against MySQL-compatible forks and services, but the core server remains actively developed by Oracle.
One practical note: if you're still on MySQL 5.7 anywhere, it reached end of life in October 2023. Migrate to 8.x; the upgrade is well-trodden.
Data types and SQL features
This is where the gap is most visible, and it favors Postgres.
JSON. Both databases have JSON support, and MySQL's is better than people remember — it has a binary JSON format, JSON path expressions, and multi-valued indexes over JSON arrays. But Postgres's jsonb with GIN indexing is more flexible in practice: arbitrary containment queries (@>), expression indexes on any extracted path, and the full SQL/JSON path language. If your schema has a genuinely dynamic document-shaped corner, Postgres handles it with less ceremony.
Types. Postgres has arrays, ranges, inet, uuid as a native type, composite types, and full custom type support. MySQL covers the standard scalar types well but stops there. Whether this matters depends entirely on your app — plenty of large systems never need a range type.
Indexes. Postgres offers B-tree, GIN, GiST, BRIN, hash, and partial/expression indexes; MySQL is essentially B-tree (plus full-text and spatial). Partial indexes in particular are something you'll miss in MySQL once you've used them — indexing only the 2% of rows where status = 'pending' is a wonderful trick for queue-like tables.
The stuff that used to differentiate and no longer does. Window functions, CTEs, and EXPLAIN ANALYZE are in both. MySQL 8 closed most of the classic SQL-feature gap. If your mental model of MySQL is from the 5.x era, it's out of date.
Performance characteristics (not benchmarks)
I'm not going to publish numbers, because workload-free database benchmarks are how people lie to each other. But the *architectural* differences produce predictable behavior:
MVCC strategy. Postgres keeps old row versions in the table itself and cleans them up with vacuum. InnoDB keeps them in undo logs and purges. Consequence: update-heavy Postgres tables need vacuum to keep up, and a neglected autovacuum eventually becomes table bloat and degraded queries. Modern Postgres has made vacuum dramatically less painful, but it's still a thing you monitor. InnoDB's failure mode is different — long-running transactions holding back purge — but day-to-day, update-heavy OLTP is the workload where InnoDB's design is most defensible. The details are worth reading firsthand: [Postgres MVCC](https://www.postgresql.org/docs/current/mvcc-intro.html) vs [InnoDB multi-versioning](https://dev.mysql.com/doc/refman/8.4/en/innodb-multi-versioning.html).
Connections. Postgres uses a process per connection; MySQL uses a thread per connection. Threads are cheaper, so MySQL tolerates high raw connection counts more gracefully, while serious Postgres deployments almost always put PgBouncer (or an equivalent pooler) in front. This isn't a reason to pick MySQL — it's a reason to budget for a pooler with Postgres, especially with serverless functions or Lambda-style compute where connection counts explode.
Complex queries. Postgres's planner is generally stronger on multi-join analytical queries, and its parallel query execution is more comprehensive. If your app leans on reporting queries against the primary, Postgres tends to degrade more gracefully.
Simple reads. For key-lookup-heavy CRUD at high concurrency, both are fast and your bottleneck will be schema design, indexes, and your ORM's laziness long before it's the engine.
Replication and HA
MySQL's replication story is older and, for the classic async primary-replica topology, simpler to operate — it's been the backbone of read-scaling web architectures for two decades, and group replication adds a consensus-based option. Postgres's streaming replication is rock-solid for HA, and logical replication has improved steadily (row filtering, column lists, two-phase commit support), narrowing what used to be a real MySQL advantage. In 2026, both get you to "replica promoted automatically when the primary dies" — the difference is mostly which ecosystem's tooling you'd rather learn.
Ecosystem gravity
This is the soft factor that decides more migrations than any feature: Postgres has become the default. New ORMs, new SaaS products, new AI tooling — they ship Postgres support first. Extensions mean Postgres absorbs adjacent workloads (vector search, geospatial, time series) that would otherwise require another system. MySQL's gravity is different: an enormous installed base, deep operational knowledge in the industry, and first-class support in the PHP/WordPress world that isn't going anywhere.
So which one, actually
Pick PostgreSQL when:
- Your schema has document-shaped, geospatial, or vector-search corners
- You run analytical queries against your transactional data
- You want the widest choice of modern tooling defaults
- You value extensions as an escape hatch for future requirements
Pick MySQL when:
- Your team already operates MySQL well — operational familiarity beats feature checklists
- The workload is classic high-concurrency OLTP with simple queries
- You're in an ecosystem (WordPress, many PHP and legacy Java stacks) where MySQL is the native choice
- You want the simplest possible async read-replica story
And the honest tiebreaker: if you have no constraint pushing you either way, pick Postgres in 2026 — not because MySQL is bad, but because the default-ness compounds. Every tool you adopt next year will support it first.
Running either one without babysitting it
Whichever you choose, the operational work — provisioning, daily backups, credential management — is the same category of chore, and it's the part worth outsourcing early. PandaStack runs both as managed databases (PostgreSQL 14.x and 16.x, MySQL 8.x in production), orchestrated on Kubernetes via KubeBlocks, with scheduled daily backups retained 7 days on the free tier and 15/30 days on paid plans. Attach a database to an app and DATABASE_URL is injected automatically, so your Prisma or Django or Rails config is one line. Connection limits scale with plan (50 on free, up to 1000 on Premium) — which, per the pooling discussion above, is a number you should actually look at before your serverless functions do.
Both engines will serve you well. Pick one, ship, and revisit only if a real constraint shows up. If you want either running with backups handled in the next five minutes, https://pandastack.io will do that.