ChatGPT Bet 800 Million Users on It: Why More Projects Are Moving from MySQL to PostgreSQL

TL;DR

It’s not that MySQL got worse — the questions changed. Ten years ago we asked “is this database fast?” Today we ask “can it store vectors, handle JSON, run complex analytics, and — will its owner still care about it tomorrow?” MySQL still aces the first question; PostgreSQL wins nearly all the rest. In the Stack Overflow 2025 Developer Survey, PostgreSQL crushed MySQL 55.6% to 40.5%. OpenAI runs ChatGPT’s 800 million users on PostgreSQL. Meanwhile, MySQL’s open-source repo once went three months without a single new commit. This post covers three things: how big this “moving wave” really is, where PostgreSQL actually wins, and — let’s stay sober — when you should still pick MySQL.

Figure 1: Cover image (self-made). A quiet “moving wave” is sweeping through the database world.

1. Background: A Quiet Wave of Moving Trucks

Rewind ten years. Around 2015, if you were building a website or an app, you picked MySQL with your eyes closed. The LAMP stack (Linux + Apache + MySQL + PHP) was the default starter kit of the internet — WordPress, countless e-commerce systems, and half the forums on Earth grew up on it. MySQL was the unquestioned “default answer.”

Ten years later, the wind has completely changed direction. The most direct evidence is the Stack Overflow 2025 Developer Survey — a questionnaire answered by nearly 49,000 developers, effectively a census of the programming world:

Figure 2: Real screenshot. PostgreSQL 55.6% vs. MySQL 40.5% — a 15-point gap. Back in 2017, MySQL led PostgreSQL by nearly 20 points. In eight years, the two sides completely swapped positions.

You might argue a developer survey measures taste, not production reality. Fair enough — then look at the DB-Engines Ranking, which blends search-engine buzz, job postings, and Q&A activity into a “rich list” of databases. Here’s the latest August 2026 edition:

Figure 3: Real screenshot. Oracle #1, MySQL #2, SQL Server #3, PostgreSQL #4. The table looks calm — until you look at the score deltas: MySQL evaporated about 97 points year-over-year, while PostgreSQL is now fewer than 10 points behind SQL Server in third place.

Zoom out to a ten-year view and the trend becomes impossible to miss:

Figure 4: Real screenshot. PostgreSQL’s curve is the only one in the top tier still climbing steadily, while Oracle, MySQL, and SQL Server all slide slowly downward. It’s like a class report card: the ranks haven’t changed, but the leader’s score is falling and the fourth-place student’s score keeps rising. Every teacher knows what happens next.

Even more convincing is where the real money went. In 2025, Databricks acquired serverless-Postgres startup Neon for roughly $1 billion, and Snowflake promptly snapped up PostgreSQL vendor Crunchy Data. The direction cloud vendors vote with their wallets is usually the keyword on architects’ resumes three years later.

2. Symptoms: MySQL’s Side Has Been Eventful — and Not in a Good Way

If PostgreSQL’s rise is “good news from the neighbor’s house,” then several events in the MySQL camp since late 2025 have been noises from inside its own yard.

Event one: the core team was gutted. In September 2025, Oracle carried out sweeping layoffs across the core MySQL development team, losing veterans with more than a decade of tenure. MySQL’s creator Monty Widenius (who later left to found MariaDB) publicly said he was “heartbroken.” Developers noticed that the open-source MySQL repository went more than three months without a single new commit after September 2025, with commit activity at the lowest point in the project’s history.

Event two: the open letter. In February 2026, nearly 200 developers signed an open letter to Oracle demanding a clear future for MySQL — either invest in it properly, or hand governance to an independent foundation.

Figure 5: Real screenshot (CODERCOPS). When a database project reaches the point of “users writing an open letter to the vendor,” it’s like homeowners collectively filing a complaint against the property management company — the trust gap is no longer just a technical matter.

Event three: a confusing versioning scheme. MySQL 8.0 reached end-of-life in April 2026, and Oracle now runs a dual track of “8.4 LTS + 9.x Innovation.” But teams upgrading discovered the 9.x line jumped several major versions within a year (from 9.0 all the way to 9.7), with legacy features removed along the way. The upgrade path feels like a highway being repaved while traffic flows — drivable, but bumpy.

To be fair, MySQL hasn’t given up: the 9.x series finally added a native VECTOR type, JSON Duality Views, and JavaScript stored programs. The problem is PostgreSQL had all of this years ago (pgvector shipped in 2021). MySQL looks like a student handing in homework the other kid turned in five years ago.

3. Analysis: Where PostgreSQL Actually Wins

Now for the technical part. PostgreSQL’s lead isn’t one or two features — it’s a systematic advantage across four dimensions. I’ll explain each with everyday analogies.

3.1 Concurrency: Editing the Original vs. Handing Everyone a Photocopy

Imagine a family photo album everyone is flipping through. Now you need to change a number on one page (a balance, from 100 to 80). There are two ways to do it:

MySQL (InnoDB) edits the original in place: strike out the old number, write the new one, and stuff the old version into a “recycle bin” called the undo log. Readers can, in theory, peek at the old version in the bin, but the implementation has limits — and under some configurations and isolation levels, readers queue up and wait.

PostgreSQL makes a photocopy: the original page stays untouched, and a new page reading “new version: 80” is added. People already reading keep reading the old page without noticing anything; new readers get the new one. Nobody blocks anybody.

These are the two implementation routes of MVCC (multi-version concurrency control). One sentence summary: MySQL keeps one original plus a recycle bin; PostgreSQL lays every version out on the table.

Figure 6: Self-made diagram. Read-heavy and write-heavy systems — orders, billing, social feeds — hate it most when readers and writers queue for each other. That is exactly PostgreSQL’s home turf.

In real business terms: your analytics team can run a ten-minute report without freezing customers mid-checkout, and the nightly reconciliation job doesn’t have to yield to daytime peak traffic.

3.2 Extensions: One Host, a Whole Wall of Lego Bricks

This is PostgreSQL’s most unfair advantage. It was designed for extensions from day one: one CREATE EXTENSION command plugs a brand-new capability into the database, like snapping Lego bricks onto a base plate:

• pgvector: store and search AI embeddings directly in PostgreSQL — do RAG without running a separate vector database;
• PostGIS: the de facto standard for geospatial data — “people nearby,” delivery-zone fences, all trivial;
• TimescaleDB: time-series extension for monitoring metrics and IoT sensor data;
• Citus: horizontal sharding that turns a single node into a distributed cluster.

Figure 7: Self-made diagram. In the AI era, the most expensive thing isn’t the database — it’s “one less migration.” Vectors, geo, time-series, sharding: PostgreSQL covers four jobs in one box.

The AI era amplified this enormously. Since 2023, almost every new project wants an “AI retrieval” layer bolted on. With MySQL, you typically end up deploying a separate vector database and then painfully keeping two systems in sync. With PostgreSQL, you install pgvector and your business rows and vectors live in the same database — one SQL query can ask for “price under 100” AND “semantically closest to this sentence.” Fewer systems means fewer 3 a.m. incident calls.

The poster child is OpenAI. In January 2026, OpenAI’s engineering team revealed the database architecture behind ChatGPT: 800 million users, millions of queries per second, running on a single-primary PostgreSQL setup (Azure PostgreSQL Flexible Server) plus nearly 50 read replicas spread across regions — with p99 latency in the low double-digit milliseconds and five-nines availability.

Figure 8: Real screenshot (StorageNewsletter, relaying OpenAI’s official blog). The world’s largest AI product runs without sharding and without a distributed SQL layer — just one PostgreSQL primary and a fleet of read replicas. The ancient claim that “PostgreSQL can’t handle big traffic” can now be formally retired to a museum.

3.3 SQL Power and Developer Experience: Sedan vs. All-Terrain Vehicle

If MySQL is a pleasant family sedan, PostgreSQL is an all-terrain vehicle with a full off-road kit. For daily commuting the difference is small; once the road gets rough, the gap becomes obvious:

• JSONB: PostgreSQL’s JSON is binary, indexable, and partially updatable — a first-class citizen. MySQL’s JSON has improved over the years, but its indexing and operator richness still lag. Toss semi-structured data (events, configs, third-party payloads) into JSONB and queries fly.
• Window functions + CTEs + recursive queries: complex reporting SQL is both writable and well-optimized in PostgreSQL; MySQL only gained window functions in 8.0, and its optimizer is still widely considered weaker on complex queries.
• Transactional DDL: the lifeline of anyone on call. In PostgreSQL, schema changes can be wrapped in a transaction — if something goes wrong halfway, roll back and the world is clean again. Most MySQL DDL cannot be rolled back; one wrong column type can mean a production incident plus half a day of data repair.

An analogy: MySQL’s SQL is a home kitchen — a stove, a pot, a knife, enough for everyday dishes. PostgreSQL’s SQL is a restaurant kitchen — add an oven, a sous-vide machine, and a full knife set. You don’t have to use them, but they’re there when you need them.

3.4 Performance Hasn’t Stood Still: PostgreSQL 18’s Async I/O

The old line against PostgreSQL was “powerful but slower than MySQL.” That line largely expired in September 2025: PostgreSQL 18 introduced a full asynchronous I/O subsystem, with official benchmarks showing up to 3× performance gains in certain storage-read scenarios, plus the ability to carry optimizer statistics across major-version upgrades (no more long “warm-up” period after upgrading).

Figure 9: Real screenshot (postgresql.org). The banner at the top even shows the freshly released 18.6 and 19 Beta 3 from August 13, 2026. Compare that heartbeat with MySQL’s three commit-free months — the two projects’ pulses are from different worlds.

4. Root Cause: Not a Technology Race — a Governance Structure

Enough technology. Time for the deeper question. Technical gaps can be closed — didn’t MySQL 9.x just add a vector type? So why is the wind still accelerating toward PostgreSQL?

Because choosing a database is fundamentally choosing “who gets to decide.” An analogy:

MySQL is like a neighborhood run by a commercial property management company. The buildings (code) are nominally open (GPL), but the management company (Oracle) calls the shots: whether the elevator gets fixed, when, and how much the fees rise — residents get no vote. When the company laid off the maintenance crew in 2025 and the security booth sat empty for months, residents realized the neighborhood’s service quality depends entirely on the owner’s quarterly earnings mood.

PostgreSQL is a homeowners’ association. Its PostgreSQL License is close to MIT/BSD — anyone can use it free, modify it, and build commercial products on it, and crucially, it belongs to no single company. Core development is driven by a global community. Cloud vendors can sell hosted versions of it (AWS, Azure, and every major cloud do), but nobody owns it — which means nobody can “take it back” or lock it behind a paywall.

Figure 10: Self-made diagram. Technical gaps close; governance structures don’t. When an architect bets five years on a stack, they’re really betting its governance model survives five years.

That’s the root cause: PostgreSQL’s rise is half a technology victory and half a migration of trust. As developers grow wary of “open-source projects controlled by a single vendor” (we’ve all seen enough license changes and post-acquisition freezes), a project with neutral governance, a permissive license, and a healthy community naturally becomes the flight-to-safety destination.

5. A Sobering Note: When You Should Still Choose MySQL

Criticizing something is easy; knowing its boundaries is hard. I won’t tell you to smash every MySQL instance you have — that would be its own kind of unprofessionalism. In these situations, MySQL remains a correct, even optimal, choice:

Figure 11: Self-made decision chart. Technology selection isn’t picking a tribe — it’s doing the math.

First, don’t touch what works. If your e-commerce system has run stably on MySQL for five years, with mature sharding, read-write splitting, and monitoring, then “migrate to PostgreSQL” is very likely a net-negative project. Database migration is risky and expensive; that’s not how you pay down technical debt.

Second, simple CRUD with extreme read concurrency. Blogs, news sites, product listings — “95% reads, trivial logic” workloads. MySQL’s architecture is light enough, the tuning literature is endless, and it pairs beautifully with a cache. The WordPress ecosystem in particular is welded to MySQL; there’s no reason to fight the ecosystem.

Third, your team’s skill set is the most expensive performance optimization. A team that can fix MySQL replication lag blindfolded will spend its first six months on PostgreSQL at reduced combat strength. When the database fails at 3 a.m., familiarity is worth more than sophistication.

Conversely, for a greenfield project — especially one that needs AI retrieval, lots of JSON/geo/time-series data, complex reporting SQL, or a team with no legacy baggage — PostgreSQL in 2026 is the “can’t-go-wrong default.” Higher ceiling, more escape routes, and no landlord.

6. Q&A

Q1: I’m learning databases now — can I start with PostgreSQL directly? Yes, and I’d recommend it. It has the most complete SQL-standard support; learning PostgreSQL first makes MySQL a “downgrade-compatible” skill, while the reverse requires catch-up. PostgreSQL job postings are also growing noticeably faster.

Q2: Will MySQL die? No. Its installed base is enormous — WordPress alone powers a huge share of the web, and countless enterprise and government systems run on MySQL/MariaDB. The more likely script is “slowly becoming legacy technology”: like COBOL, fewer and fewer new projects will choose it, but maintenance demand will persist for many years.

Q3: What are PostgreSQL’s real weaknesses? Honestly: its connection model is heavy (one process per connection, so you need a pooler like PgBouncer at high concurrency); table bloat requires watching vacuum health; the default configuration is conservative and production tuning is mandatory; and its major-version upgrades, though improving every year, are still more involved than MySQL 8.0-era in-place upgrades.

Q4: Where do distributed SQL databases (TiDB, CockroachDB, etc.) fit in this story? Closely — many of them borrow mindshare by speaking one of the two wire protocols. Several newer engines are built on or evolved from PostgreSQL, while others primarily speak the MySQL protocol. In other words, the rise and fall of these two ecosystems also shapes which camp the next generation of databases joins.

Q5: How hard is migrating from MySQL to PostgreSQL? For small-to-medium databases (hundreds of GB), not that hard — tools like pgloader cover most cases. The hard parts are controlling downtime windows on big databases, rewriting stored procedures and triggers (the dialects differ a lot), and rebuilding the operational playbook. Pilot with an edge service first; only talk about core databases after a full release-rollback-scale cycle.

Q6: What about MariaDB? Can it catch MySQL’s users? MariaDB catches the “pure GPL open source” crowd and has been adding vector search and other AI capabilities. But objectively, its scale and ecosystem have fallen behind the two main lines — it sits at #13 on DB-Engines in August 2026. It’s an honest spare tire, not the next protagonist.

7. Closing

The whole moving wave can be summed up in one sentence: MySQL won one era; PostgreSQL is winning the next.

MySQL’s golden age asked, “how do you survive the traffic?” PostgreSQL’s golden age asks, “how do you fit an entire AI application inside one database?” Neither answer is wrong — the exam simply changed.

For architects, the lesson worth remembering isn’t actually these two names, but the underlying rule: when choosing infrastructure, look at governance first, ecosystem elasticity second, and benchmark scores last. Benchmarks change every year; who owns a project’s future determines whether you’ll be moving house at midnight five years from now.

---

References: Stack Overflow 2025 Developer Survey, DB-Engines Ranking, OpenAI: Scaling PostgreSQL to Power 800 Million ChatGPT Users, PostgreSQL 18 Released, MySQL’s Open Letter to Oracle, PostgreSQL vs MySQL 2026.