How to Choose Between Postgres and MySQL: Five Questions, Not Benchmarks

Every new project starts with the same quiet question: Postgres or MySQL? The standard answer in 2026 is "just default to Postgres" — and it's right more often than it's wrong. But "more often" is doing a lot of work in that sentence. I spent this week in the 2026 release notes, benchmarks, and operational war stories so you don't have to. The honest version: the decision isn't settled by benchmarks. It's settled by five practical questions.

The benchmarks won't settle this for you

Every Postgres vs MySQL post opens with a benchmark table, and nearly every one of those tables is lying by omission. Both databases ship defaults sized for a laptop — shared_buffers and innodb_buffer_pool_size both default to 128MB — so most published benchmarks measure configuration, not engines. On tuned hardware, most workloads land within about 30% of each other, and the right index matters 10x to 1000x more than the engine choice.

That said, the edges are real and they're workload-shaped. MySQL is genuinely faster at simple single-table OLTP and read-heavy work — up to ~21% higher peak TPS in sysbench-style tests, and Oracle moved the Thread Pool into Community in MySQL 26.7. Postgres wins where queries get complicated: multi-table joins, window functions, JSONB queries, full-text search — and PostgreSQL 18's async I/O pushes storage-bound reads up to ~3x faster. At extreme write intensity, MySQL's InnoDB has one more edge — old row versions live in the undo log, so heavily updated tables never bloat — but unless you're at Uber's scale, treat all of this as tiebreakers, not deciders.

Question 1: What does your team already know?

This is the boring answer and the correct one. A team fluent in MySQL ships a safer system on MySQL than on a Postgres it will learn by incident. Postgres has a learning curve MySQL doesn't. If your team already runs one of them well, the decision is mostly made.

The Stack Overflow Developer Survey 2026 (published October 7) puts numbers on the drift: 57.9% of developers used PostgreSQL in the past year versus 35.1% for MySQL — its fourth straight year topping "most used" and "most admired." DB-Engines' October 2026 snapshot tells the other half: MySQL is still #2 overall (837.96) ahead of Postgres at #4 (688.75) — incumbency versus momentum. Hire for the fleet you have.

Question 2: What shape is your data?

This is where the engines genuinely differ. If your application queries inside semi-structured JSON, Postgres's JSONB is the better document store and it isn't close: one GIN index covers the entire document at once. In MySQL you can't index a JSON column directly — you add a generated column over one specific path and index that, by hand, per path. (MySQL 9.6's JSON Duality Views are a clever counter-move: read and write JSON documents while the server stores normalized relational rows. Postgres has no equivalent.)

For AI workloads the gap is wider. pgvector's HNSW and IVFFlat indexes are the standard for RAG and semantic search inside one ACID database — one CREATE EXTENSION and your existing Postgres does vectors. MySQL has had a native VECTOR type since 9.0, but through MySQL 26.7 the Community Edition still lacks native distance functions and ANN indexing; DISTANCE() lives in the proprietary HeatWave tiers. If your roadmap has "add vector search," that's nearly a one-question decision.

Geospatial is the same story: PostGIS is the industry standard, full stop. And the extension ecosystem is Postgres's deepest structural advantage — pg_cron for scheduled jobs, TimescaleDB for time series, foreign data wrappers that query other systems — 400+ catalogued extensions, all coexisting in one database. MySQL never grew an equivalent extension culture.

Question 3: How will you run it?

Databases are not just query engines; they're things you operate at 3 AM. MySQL's high-availability story is simpler to adopt: Group Replication gives you multi-primary-capable HA with automatic primary election inside the server, and 26.7's Change Stream Applier finally answers replica lag under write bursts. Postgres's replication is flexible — WAL streaming plus logical publish/subscribe — but failover orchestration is not in core. Production Postgres HA means Patroni or equivalent, run by you.

Then there's the tax each engine charges. Postgres charges it as operational literacy: MVCC keeps old row versions in the table, so heavy update/delete workloads bloat tables and need vacuuming — and the quiet catastrophic version, MultiXact member exhaustion, is invisible on standard dashboards. Postgres also uses a process-per-connection model — roughly 2ms per new connection versus MySQL's ~0.8ms — so careless connection handling melts a Postgres instance. A pooler like PgBouncer is not optional in production.

MySQL charges its tax as upgrade discipline. MySQL 8.0 went end-of-life in April 2026, and Oracle switched to calendar versioning: MySQL 9.7.0 LTS is the production baseline, 26.7.0 Innovation shipped July 2026, and there will never be a 9.8. Upgrades must follow compatibility lineages — 8.4 to 9.7 to 26.7 — so for the world's largest MySQL fleets, 2026 was a project, not a patch. If you're already on 8.0, your near-term decision is "upgrade to 9.7," not "Postgres or MySQL." Don't stack a cross-engine migration onto a forced upgrade deadline. Two risky projects, one deadline.

Question 4: Are you shipping the database itself?

For most web apps this question doesn't apply — but when it does, it overrides everything else. PostgreSQL's license is liberal, BSD/MIT-style: embed, fork, ship commercial products, no obligations. That's why every modern app platform standardized on it. MySQL Community is GPLv2: if you distribute MySQL bundled inside your commercial software, the GPL requires your software to be under a GPL-compatible license — or you buy a commercial license from Oracle. Running MySQL behind your SaaS is unaffected (no distribution of the server itself), which is why cloud MySQL thrives; but appliances, OEM embeds, and shipped on-prem software hit a real decision point, and it's Oracle on the other side of the table. It's also why MariaDB exists. Postgres has no enterprise/community split — what you download is what everyone runs.

Question 5: What happens when you outgrow the choice?

The last question is the one people ask least and regret most. Data movement is the easy part — pgloader moves MySQL to Postgres in one command, schema discovery plus parallel COPY. The real cost is the application: the dialect conversions (AUTO_INCREMENT to SERIAL, ON DUPLICATE KEY UPDATE to ON CONFLICT, backticks to double quotes), rewritten stored procedures, and the gotcha that bites first — a MySQL "database" is closer to a Postgres schema than a Postgres database. Budget weeks to months for a production app with heavy MySQL-isms. One skeptical look at the consensus: "Postgres for everything" is one operational surface, but each workload deserves a conscious check before being folded in — a default this strong stops feeling like a choice.

So what do you actually do?

Run the five questions in order. If your team knows one engine well and the workload is ordinary, stop there — ship on what you know. Starting fresh with no legacy: Postgres is the 2026 default — extensions, JSONB, the managed ecosystem, the license, and the hiring market all agree. But the consensus is wrong in three specific, common cases: you're sitting on a MySQL 8.0 fleet (upgrade to 9.7, don't migrate); extreme write-intensive OLTP at serious scale (InnoDB skips the bloat tax); or your workload is simple, read-heavy, and your team already speaks MySQL.

Do this today: write down which of the five questions is doing the most work, and what would flip it. If you can't name the question, you don't have a decision yet — you have a preference wearing a benchmark table as a disguise. Whichever you pick, a well-tuned instance beats a neglected one — of either engine.

References

• Bytebase — "Postgres vs MySQL" 2026 deep-dive
• Stack Overflow Developer Survey 2026 — Databases
• DB-Engines Ranking (October 2026)
• Oracle MySQL Blog — July 2026 GA releases (calendar versioning)
• Percona — Meet MySQL 26.7: a new versioning era begins
• SQLpassion — What's new in PostgreSQL 18
• Severalnines — PostgreSQL 18 upgrades for AI-era workloads
• TecHearl — Storing JSON/JSONB in PostgreSQL
• Redgate Simple Talk — MySQL vs PostgreSQL: JSON data type
• CommandLinux — MySQL vs PostgreSQL benchmark data on Linux
• JK Tech Hub — MySQL vs PostgreSQL 2026
• PingCAP — Vector similarity search in MySQL
• pbxscience — Postgres keeps climbing, but MySQL's big 2026 story is a foundation, not a funeral
• Umur Inan — Postgres won the database war. Now what?
• Convert-in — Migrating from MySQL to PostgreSQL using pgloader
• Estuary — MySQL to PostgreSQL migration guide
• WordPress.org — Hosting requirements
• DEV Community — PostgreSQL vs MySQL: Database Selection Guide for Developers (2026)