Two sets of numbers about databases in 2026 point in opposite directions. In the 2025 Stack Overflow Developer Survey, 55.6% of all respondents said they had done real work with PostgreSQL in the past year, compared with 40.5% for MySQL. Yet the DB-Engines popularity ranking for March 2026 still had MySQL comfortably ahead, with a score of 858 against PostgreSQL's 680.

So which one is winning? It depends on what you count. The survey asks developers what they used recently. DB-Engines looks at search traffic, job ads, and forum questions, and a database that has run a big slice of the web for almost 30 years leaves a large footprint there.

That split is a good preview of the whole MySQL vs PostgreSQL debate. Both are free, mature, and running huge production systems right now. The real differences hide in the details: how each treats messy data, what happens when 500 people tap "buy" in the same second, and what breaks first when your app grows ten times bigger than planned.

This guide walks through those details in plain language, no database background needed.

First, what are we actually comparing?

MySQL and PostgreSQL are each a relational database. The idea is simple. Your data lives in tables that look like spreadsheets, with a row for each record and a column for each detail. An orders table holds an order number, an amount, and the ID of the customer who placed it. That shared customer ID is the "relation," linking each order back to a row in the customers table.

You talk to both using SQL (Structured Query Language), a way of asking questions like "show me every order over $100 from last week." Most everyday SQL works the same in both.

MySQL appeared in 1995 and became the "M" in the LAMP stack (Linux, Apache, MySQL, PHP) that powered much of the early web. Oracle has owned it since buying Sun Microsystems in 2010. PostgreSQL began as a University of California, Berkeley research project in the 1980s and is run by an independent community with no single company in charge. That ownership difference matters more in 2026 than it used to.

The 2026 scoreboard

Here is where the two stand right now. A couple of these figures are reported inconsistently elsewhere, which is explained after the table.

Market snapshot, September 2026

Some articles quote PostgreSQL's 55.6% as the professional-developer figure. That is the all-respondents number; the professional figure is 58.2%. You will also see claims that 2025 was the first year PostgreSQL passed MySQL. Stack Overflow's own 2024 report called PostgreSQL the most popular database for the second year running, which puts the crossover in 2023. PostgreSQL's "admired" score also appears as 64.7% (EnterpriseDB) and 65.5% (other write-ups). The direction is consistent; the decimals are not.

One counterweight: OpenLogic's State of Open Source Report, cited in May 2026, found MySQL in use at nearly 52% of organizations. New work may be drifting toward PostgreSQL, but a huge amount of existing software still runs on MySQL.

Round verdict: New projects are moving toward PostgreSQL. The installed base still leans heavily toward MySQL. Hiring for either is easy.

Round 1: How each one stores and changes your data

Both databases let many people read and write at once using MVCC (multi-version concurrency control). When someone changes a row, anyone who started reading a moment earlier keeps seeing the old version until they finish, so readers and writers don't block each other.

Where the two differ is what happens to that old version.

PostgreSQL never edits a row in place. An update writes a whole new copy and marks the old one dead, like crossing out a line in a notebook and writing the correction at the bottom. Someone has to erase the crossed-out lines eventually. That cleanup is called VACUUM, and a background process (autovacuum) runs it.

In a MySQL database using InnoDB, the default storage engine, the row is changed where it sits. The old version goes into a side notebook called the undo log, and a process called purge clears it out later.

What this looks like under pressure

Say a users table has a "last seen" timestamp that updates every time someone opens your app.

▪         In PostgreSQL, every one of those updates leaves a dead row behind. If autovacuum falls behind, the table "bloats" (grows far bigger than its live data) and scans slow down. New row versions can also force index updates, called write amplification. Uber's engineering team cited this in 2016 as a main reason for moving a large system from PostgreSQL to MySQL.

▪         In MySQL, the same pattern is cheaper because the row stays put. Its weak spot is different: one transaction left open for a long time (a slow report, a forgotten session) stops purge, the undo log grows, and the server gradually slows.

▪         Long-running transactions hurt PostgreSQL too, because they stop VACUUM from removing dead rows. "Don't leave transactions hanging" applies to both.

One more storage detail: InnoDB keeps each table physically sorted by its primary key. If that key is a random UUID (a long random ID), new rows land in random places and inserts slow as the table grows. PostgreSQL 18 added a uuidv7() function that creates IDs in rough time order.

PRO TIP

If you use UUIDs as IDs in either database, pick time-ordered UUIDv7 over fully random ones. Inserts stay fast and indexes stay compact as tables reach the millions.

Round verdict: MySQL handles constant updates to the same rows with less cleanup. PostgreSQL copes if someone watches autovacuum.

Round 2: Messy data, missing values, and silent surprises

A partner sends a CSV file with blank fields, a date of 30 February, and a 400-character product name. What the database does next tells you a lot.

PostgreSQL is strict. If a value doesn't fit the column type, the insert fails. Annoying during imports, but bad data doesn't slip in quietly.

Older MySQL versions were lenient: they cut long text short and turned impossible dates into '0000-00-00' with only a warning. Strict mode has been the default since MySQL 5.7 (2015), but many hosting setups and older apps switch it off for compatibility. Before you trust how your MySQL database handles bad input, run SELECT @@sql_mode; and check that STRICT_TRANS_TABLES is in the list.

Case sensitivity causes real bugs. MySQL's default collation (its rules for comparing text) treats "Bob@mail.com" and "bob@mail.com" as the same, and even "resume" and "résumé." PostgreSQL treats them as different unless you use the citext extension or index lower(email). During a migration, the same "is this email already registered?" check gives two different answers, and duplicate accounts can appear overnight.

Emoji are the other trap. MySQL's old "utf8" character set can't store most emoji. New installs use utf8mb4, but tables created years ago may not, and a customer's review simply fails to save.

A quieter data gap: MySQL before 8.0.16 (2019) accepted CHECK rules in table definitions and ignored them. If your schema dates from then, don't assume existing data follows those rules.

Round verdict: PostgreSQL is stricter out of the box. MySQL can match it, depending on settings someone may have changed years ago.

Round 3: Asking questions quickly (queries and SQL optimization)

For every query, a part called the query planner picks how to find the answer, much like a GPS picking a route. It uses statistics about your data, such as row counts and how values are spread, to guess the quickest path.

PostgreSQL's planner has more routes. It joins tables several ways and runs parts of big queries in parallel across CPU cores, which suits reports with many joins.

MySQL's planner has been simpler but excels at what web apps do all day: "get this user by ID," "get this customer's last 20 orders." MySQL 9.7 LTS (April 2026) brought the newer Hypergraph optimizer to the free Community edition, though reviewers note it is switched off by default.

Reading the planner's mind

The single most useful habit in SQL optimization is asking the database to explain itself. Both support EXPLAIN ANALYZE, which runs the query and shows the route it took:

EXPLAIN ANALYZE

SELECT customer_id, SUM(amount)

FROM orders

WHERE created_at >= '2026-09-01'

GROUP BY customer_id;

Look for two things in the output. A "Seq Scan" (PostgreSQL) or "Table scan" (MySQL) on a large table means every row was read, which usually means a missing index. And if the planner estimated 50 rows but got 500,000, its statistics are stale.

That is a classic conflicting signal. Take an orders table where 99% of rows are "delivered" and 1% "pending." Pending orders should be found through an index; delivered ones by reading the whole table. With old statistics, or one saved plan reused for both values (common with prepared statements), the database picks the wrong route for one. ANALYZE refreshes statistics in PostgreSQL; in MySQL, ANALYZE TABLE ... UPDATE HISTOGRAM helps with lopsided columns like this.

PostgreSQL 18 (25 September 2025) also added asynchronous input/output, letting the database request several chunks from disk at once. Developers reported two to three times faster full-table scans and vacuum work on suitable storage.

PRO TIP

Before paying for a bigger server, run EXPLAIN ANALYZE on your five slowest queries. In a lot of slow apps, the fix is one or two missing indexes, and good SQL optimization costs nothing but an afternoon.

Round verdict: PostgreSQL has the stronger planner for complex reports. For simple lookups, indexing matters more than the database.

Round 4: Split-second decisions under real traffic

One seat is left. Five hundred people tap "Buy" in the same second. Exactly one should get it.

Both databases handle this the same basic way. SELECT ... FOR UPDATE locks the seat's row, the others wait, and when the first finishes they see the seat is gone. Both support SKIP LOCKED too, which lets job-queue workers grab "the next unclaimed task" without fighting over the same one.

▪         Default isolation level. MySQL defaults to REPEATABLE READ, where a transaction sees a frozen snapshot from its first read. PostgreSQL defaults to READ COMMITTED, where each statement sees the latest saved data. The same code can behave differently on each.

▪         Gap locks in MySQL. Locking a range in MySQL, such as "Room 12 bookings from 3pm to 5pm," also locks the empty space between rows. That prevents double-booking but causes surprise waits and deadlocks on inserts that look unrelated.

▪         Exclusion constraints in PostgreSQL. PostgreSQL can enforce "no two bookings for one room may overlap" as a table rule, refusing the second booking however many requests arrive at once.

▪         Serializable mode. In the strictest setting, PostgreSQL may cancel a transaction with a "serialization failure" and expects your app to retry.

Both databases also cancel one side of a deadlock (two transactions each waiting for the other). Without retry logic, the customer sees an error page.

When traffic jumps ten times overnight

The connection issue bites teams on serverless platforms, where every function call may open its own connection. Most managed PostgreSQL services include a pooler, but confirm it before launch, not during an outage.

Round verdict: PostgreSQL has better tools for keeping data correct under contention. MySQL handles connection floods more gracefully. Write retry logic either way.

Round 5: Growing big (replication, sharding, and scale)

Most apps scale reads first: one main server (the primary) takes every write, and copies (replicas) handle reads.

OpenAI gave a striking example of how far this can go. In January 2026, the company described running ChatGPT and its API platform for around 800 million users on a single primary PostgreSQL server on Azure, with close to 50 read replicas spread across regions. It protected that single writer with pooling and rate limits and moved splittable write-heavy workloads to Azure Cosmos DB. A well-run primary with replicas goes much further than most startups will ever need.

MySQL has its own giants. Vitess, a system for splitting MySQL data across many servers, was built at YouTube and later used by Slack and PlanetScale, and Shopify runs MySQL at very large scale.

Where scaling gets tricky

Replicas create their own data gap. Replication is usually asynchronous, so a user updates a profile photo, the page reloads from a replica half a second behind, and the old photo appears. They upload again, and now there's a duplicate. The fix is sending that user's reads to the primary briefly after a write, an app design choice neither database makes for you.

Failover, what happens when the primary dies, is the other hard part. MySQL has built-in Group Replication; PostgreSQL usually relies on tools like Patroni or a managed service. The failure to fear is "split brain," where two servers both think they are primary and accept different writes.

For splitting writes across servers (sharding), MySQL has Vitess and PostgreSQL has Citus, owned by Microsoft. Both add complexity most businesses never need.

Money is flowing toward PostgreSQL. Databricks agreed to buy serverless PostgreSQL company Neon for about $1 billion in May 2025, and Snowflake announced plans to buy Crunchy Data for roughly $250 million a month later.

Round verdict: Both scale very far. MySQL has longer sharding experience; PostgreSQL has the momentum.

Round 6: JSON, maps, and AI features

Apps often store data that doesn't fit neat columns, like user settings or product attributes. Both databases support JSON for this. PostgreSQL's JSONB can index every key in a document with one GIN index; MySQL usually needs a generated column per searchable field. For heavy JSON searching, PostgreSQL is easier.

AI features show the widest gap. Chatbots and smart search rely on "embeddings," lists of numbers capturing the meaning of text, and finding similar items is called vector search.

PostgreSQL does this with pgvector, an extension offered by the major managed PostgreSQL services. That lets you keep AI data right next to your customer and order records in one relational database, and filter by both in one query ("find support articles similar to this question, but only for customers on the Pro plan").

MySQL added a VECTOR type in 9.0, but its own 9.6 manual states that the DISTANCE() function for comparing vectors is only in HeatWave on Oracle Cloud and MySQL AI, not the Community or Commercial editions. Oracle's MySQL team said in May 2026 that native vector search is still being built.

For maps, PostgreSQL has PostGIS, which adds hundreds of spatial functions. MySQL covers basics like "find stores within 5 km."

If you hire an outside team to build AI features, this round often decides everything, since PostgreSQL saves you running a separate vector database.

Round verdict: PostgreSQL, clearly. Extensions are its biggest advantage.

Round 7: Upgrades, licenses, and who is steering

MySQL 8.0 reached end of life in April 2026, with version 8.0.46 as the final release. The free Community edition gets no more security patches, and Oracle's April 2026 update alone held 34 MySQL fixes. AWS began charging extra for RDS instances on 8.0 from August 2026; Google Cloud's paid extended support starts January 2027. If you run an older MySQL database, the upgrade path is 8.4 LTS first (supported until 2029) and then 9.7 LTS, because MySQL doesn't let you skip an LTS version.

An edge case from the 9.7 launch: InfoQ reported in May 2026 that a repository bug silently switched 8.4 users to 9.7, so a routine package update could jump a major version. Pin your database version in production.

The same report described worry about declining development activity and Oracle layoffs, while Oracle works to reassure users. Forks like MariaDB and Percona Server exist partly as insurance, but it is fair to weigh this for a ten-year choice.

PostgreSQL ships one major version a year with five years of support. PostgreSQL 19 reached beta 4 on 24 September 2026, with a release candidate due in early October, after the team pulled several features for more review. It adds REPACK CONCURRENTLY, which reclaims space from bloated tables without blocking reads and writes.

On licensing, MySQL Community's GPLv2 mostly matters if you ship software bundling MySQL; for a SaaS app it rarely does. PostgreSQL's license is very permissive.

Round verdict: PostgreSQL has steadier releases and independent governance. MySQL users should plan 2026 upgrades carefully.

Everything side by side

Here is the whole MySQL vs PostgreSQL comparison in one place.

Exceptions: when the usual advice is wrong

"Pick PostgreSQL for new projects" is common advice in 2026, and it is often right. Here are the cases where it isn't, or where the choice matters less than you'd think.

▪         You run WordPress, WooCommerce, Magento, or a similar PHP platform. These are built and tested on MySQL or MariaDB. Swapping the database brings you pain and no benefit.

▪         Your team knows one of them deeply. At 2 a.m. during an outage, deep familiarity is worth more than any feature on this list.

▪         Your hottest data is counters, sessions, or rate limits. MySQL handles these update patterns more cheaply, although many teams move this data to Redis instead and keep either database for the rest.

▪         You need heavy analytics over billions of rows. Neither is the right tool for that job alone. Most teams add a data warehouse such as ClickHouse, BigQuery, or Snowflake alongside their main database.

▪         You are migrating from one to the other. Expect trouble in specific places: case-insensitive comparisons that suddenly become case-sensitive, '0000-00-00' dates PostgreSQL refuses to accept, auto-increment IDs that need to become sequences, and GROUP BY queries MySQL allowed but PostgreSQL rejects. Tools like pgloader help, but budget time for testing, and treat SQL optimization as a fresh job after the move, since the old indexes may not suit the new planner.

So, which database wins in 2026?

It's easier to answer with your situation in front of you. Here are the most common ones.

Your situation: We're a startup building a new SaaS product with no existing code.

Our take: Go with PostgreSQL. The strict data handling, extensions, and AI support give you more room to grow, and hiring for it is easy.

Your situation: We run a WordPress site or a PHP app that already works well.

Our take: Stay on MySQL, and make sure you are on 8.4 LTS or newer. Switching would cost time and bring little in return.

Your situation: We're adding a chatbot or smart search to our product.

Our take: PostgreSQL with pgvector, so your AI data lives next to your business data without a separate vector system.

Your situation: Our app does millions of simple reads and constant small updates.

Our take: Either works. MySQL has a slight edge on update-heavy tables; PostgreSQL works well with autovacuum tuning. Your indexes will matter more than the choice.

Your situation: We're still on MySQL 8.0.

Our take: Upgrade soon. Security patches have stopped, and cloud providers are adding charges. Treat this as a chance to decide whether to stay on MySQL or move.

The honest overall answer is that PostgreSQL is the better default for most new projects in 2026. It wins on data safety, extensions, AI features, and where the community and investment are heading. MySQL is still a dependable, fast, well-understood choice, and in several of the situations above it is the right one.

Key takeaways

1.      Developer surveys favor PostgreSQL, while DB-Engines still shows MySQL with a larger overall footprint. Both numbers are real.

2.      PostgreSQL needs its autovacuum watched on busy tables. MySQL needs long-running transactions kept in check.

3.      Check sql_mode on any MySQL server you inherit, because strictness depends on settings.

4.      Use EXPLAIN ANALYZE before buying hardware. Missing indexes are a very common cause of slowdowns.

5.      PostgreSQL needs a connection pooler for high connection counts, especially on serverless platforms.

6.      For AI and vector search, PostgreSQL with pgvector is far ahead of standard MySQL in 2026.

7.      MySQL 8.0 no longer gets security patches, so plan the move to 8.4 or 9.7 now.

Where this leaves you

The MySQL vs PostgreSQL argument has gone on for over twenty years, and 2026 hasn't ended it. What has changed is the default. A few years ago, MySQL was the automatic pick for a new web app. Today, most new projects start on PostgreSQL, and the reasons are practical: stricter handling of bad data, a planner that copes well with complex questions, and an extension system that turned it into a home for JSON, maps, and AI data.

That doesn't make MySQL a bad choice. It runs a large share of the web, it is quick at the simple work most apps do, and there are more people who know how to run it than almost any other relational database. If yours works, keep it, upgrade it, and put your energy into indexes and query habits. If you are starting fresh, PostgreSQL is the safer bet. Either way, the database you understand and look after will beat the one you picked from a headline.