Comparison
Postgres or MySQL? The default flipped, with limits
The verdict
For a greenfield project in 2026, pick Postgres. New projects choose it over MySQL roughly three to one, published benchmarks put it multiple times ahead on complex queries and concurrent writes, and pgvector makes it the only one of the two that is genuinely ready for embedding workloads. Keep MySQL when you are running WordPress, WooCommerce, Magento or another CMS whose entire ecosystem is tuned for it, when your team already has years of MySQL operational muscle memory, or when you need Vitess-style horizontal sharding, which has no equally proven Postgres equivalent.
Version tracking got harder this year. Oracle's July 2026 releases were MySQL 26.7.0 Innovation, MySQL 9.7.2 LTS and MySQL 8.4.11 LTS - the 26.7 number is calendar versioning, not a leap from version 9 to version 26. MySQL 9.7 was the first major LTS since 8.4 and moved several previously commercial features into Community Edition. Postgres 18 shipped async I/O and uuidv7() in late 2025; Postgres 19 was in beta through mid-2026.
MySQL vs Postgres on features, speed and operations
Benchmark numbers in this table are published third-party claims. Both databases are fast enough that configuration, indexing and schema design will dominate your results long before the engine choice does.
| Dimension | PostgreSQL 18 | MySQL 8.4 and 9.7 LTS |
|---|---|---|
| Complex queries | One published suite measured 0.6 to 0.8 ms per complex query against MySQL's 9 to 12 ms. CTEs, window functions and lateral joins are first class. | Improving. The Hypergraph optimizer in recent releases is the biggest planner change in years, but it is still catching up. |
| Read throughput | One high-volume read test reported 23,441 queries per second against MySQL's 6,300, with far lower tail latency. | Still faster in practice for WordPress and similar CMS workloads by 20 to 35 percent, because the queries and indexes were designed for it. |
| JSON | JSONB is binary, indexable with GIN, and roughly three to four times faster on query workloads. | JSON type is functional and improving, but indexing it requires generated columns and more ceremony. |
| Vector and AI | pgvector is mature and integrates natively with LangChain, LlamaIndex and every major AI framework. | A VECTOR type arrived in 9.0, but the surrounding ecosystem is thin. Most teams bolt on a separate vector store. |
| Extensibility | PostGIS, TimescaleDB, pg_cron, custom types and custom operators. You can extend the database rather than working around it. | Plugin surface is far narrower. What ships is what you get, though 9.7 added dynamic data masking and OpenID authentication. |
| Scaling out | Read replicas plus logical replication. Sharding means Citus or application-level partitioning. | Vitess is battle-tested at very large scale and is the strongest structural argument left for MySQL. |
| Versioning clarity | One annual major, five years of support, predictable. Upgrades between majors are the routine kind of hard. | Two tracks: LTS lines (8.4, 9.7) and calendar-versioned Innovation releases. Know which one you are on before you install. |
When each database is the right call
Choose Postgres when
- The project is new and nothing in your existing infrastructure forces the other answer.
- You store embeddings, geospatial data, time series, or documents alongside relational rows.
- Your queries use CTEs, window functions, or recursive traversal and you would like them to be fast.
- You want row level security so multi-tenant isolation lives in the database rather than in every query.
- You want the modern managed ecosystem: Supabase, Neon, Prisma Postgres and every serverless provider target it first.
Choose MySQL when
- You are running WordPress, WooCommerce, Magento or Drupal, where every plugin, index hint and hosting guide assumes MySQL.
- Your team has runbooks, monitoring, and on-call experience for MySQL. That is worth more than a benchmark.
- You need horizontal sharding today and want Vitess, which has more production mileage than any Postgres equivalent.
- Cheap commodity hosting matters: shared and low-cost VPS plans still default to MySQL almost everywhere.
- Your workload is high-volume simple reads on a well-indexed schema, where the planner advantage never gets exercised.
What a migration actually costs
The single most common mistake in this comparison is treating a running MySQL system as a problem to solve. It is not. If MySQL is serving your traffic, your team knows how to operate it, and nothing on the roadmap needs a Postgres-only feature, migrating buys you a benchmark chart and a quarter of risk. The correct time to switch is when a specific requirement arrives that MySQL cannot meet, and "Postgres is better" is not a requirement.
When the requirement is real, price the work honestly. Schema and data movement is the easy part; tools handle it. The expensive parts are the SQL dialect differences your ORM did not abstract, the stored procedures nobody has read since 2019, the ON DUPLICATE KEY UPDATE statements that become ON CONFLICT, case-sensitivity behavior that silently changes, and every report built on MySQL-specific date functions. Add the replication cutover plan and the rollback plan, and a mid-sized application is a multi-week project with a real chance of a bad weekend.
Going the other direction is rarer but worth noting: teams moving Postgres to MySQL almost always do it for Vitess-style sharding or because a platform requirement forced it. If that is you, expect to give up JSONB indexing, extensions, and transactional DDL, and plan the application changes accordingly rather than discovering them during the cutover.
One neutral point in MySQL's favor that gets lost in the benchmark noise: MySQL 9.7 pulled several features that used to sit behind the Enterprise license into Community Edition, including dynamic data masking and OpenID authentication, alongside a much improved MySQL REST Service. If you evaluated MySQL against Postgres two or three years ago and filed it away, the feature gap you remember is narrower than it was. Release notes are at dev.mysql.com and postgresql.org.
Where this fits in a full stack
The database layer lists the managed providers for both engines and the serverless options that scale to zero. Because the CMS ecosystem is the strongest reason left to run MySQL, the ecommerce stack guide is where that tradeoff gets decided in practice.
For the query syntax itself, including the dialect differences that make migrations expensive, see the SQL cheatsheet. Other close calls are collected in the comparisons index.