PostgreSQL vs MySQL (2026): An Honest Comparison With Our Own Benchmark

PostgreSQL vs MySQL is the first big architecture decision in almost every web project, and it is usually made on gut feeling. Here is the short answer up front: for a new project with no constraints, we pick PostgreSQL. It is stricter with your data, it can do more, and in our own test it was three to seven times faster at analytical queries. MySQL remains the right choice when your software requires it (WordPress, Shopware, Magento and many PHP applications), when your host only offers MySQL, or when your team has been running MySQL in its sleep for years.

So that this isn’t just an opinion, on October 10, 2026 we ran both databases on the same server with exactly the same data: PostgreSQL 17.11 and MySQL 8.4.11 (the current LTS line that ships in most Linux distributions and Docker setups), each from the official Docker image, with default configuration, and limited to 2 CPU cores and 2 GB of RAM. Three results up front:

1. Right after startup, PostgreSQL used 24 MB of RAM, MySQL 424 MB. On a small VPS, that is a real difference.

2. An aggregation over 2 million orders (group by city) took about 105 ms in PostgreSQL and about 670 ms in MySQL. A join across two tables: about 200 ms versus 1.4 seconds.

3. For “give me exactly this one record via an index”, both were equally fast, roughly one millisecond. For the typical website that reads individual records, the speed difference is practically irrelevant. It only shows up in analytics.

PostgreSQL vs MySQL: What the two databases have in common

Before we get to the differences: both are relational databases. You create tables with columns, link them through keys, and query them with SQL. A SELECT name FROM customers WHERE city = 'Berlin' works identically in both. Both are open source and free to use, both run on any Linux server, both support transactions, indexes, foreign keys, replication and JSON columns. If you learned SQL basics on one, you’ll find your way around the other within a few hours.

The differences are not about whether they can do something, but how: how strict they are with wrong data, how they work internally, how much memory they need, what they can do beyond the standard, and who stands behind them.

Who is behind PostgreSQL

PostgreSQL began in 1986 as the research project “Postgres” at the University of California, Berkeley, led by Michael Stonebraker. Since the late 1990s it has been called PostgreSQL and is developed by the PostgreSQL Global Development Group, a community without a single owner. Employees of many companies (including EDB, Microsoft, Amazon and Crunchy Data) contribute, but no company owns PostgreSQL. The license is the very permissive “PostgreSQL License”, comparable to MIT or BSD: you may use, modify and even embed the code in closed products.

There is one major release per year, and each is supported with bug fixes for five years. The current stable version is PostgreSQL 18 (released September 2025). According to the official roadmap, PostgreSQL 19 is planned for October 2026; the fourth beta was published on September 24, 2026. We deliberately tested version 17, because that is what most production setups and hosting offers currently run.

Who is behind MySQL

MySQL dates from 1995 and was written by the Swedish company MySQL AB (co-founder Michael “Monty” Widenius named it after his daughter My). Sun Microsystems bought MySQL in 2008, and in 2010 Oracle acquired Sun and with it MySQL. Since then MySQL has belonged to a single company. There is a free Community Edition under GPLv2 and commercial editions with extra features.

Worried about exactly that acquisition, Widenius started the fork MariaDB in 2009 (named after his second daughter, Maria). MariaDB is largely compatible with MySQL but has diverged in details over the years. Many Linux distributions now actually install MariaDB when you ask for MySQL, which regularly confuses beginners. On our own server, mysql --version reports MariaDB 10.11.14, even though the command is called mysql.

MySQL itself saw a lot of change in 2026: MySQL 8.0 reached end of life in April 2026, and the current long-term versions are 8.4 LTS and 9.7 LTS (released April 2026, the first new LTS since 8.4). For future versions Oracle has switched to calendar versioning: MySQL 26.7 stands for the July 2026 release. If you are still on 8.0, don’t postpone your upgrade any longer.

Compact introduction by IBM Technology (December 2022). The fundamental differences still apply; version numbers in the video are older.

The differences at a glance

According to the Stack Overflow Developer Survey 2025, PostgreSQL is now the most-used database among professional developers, at over 55 percent and with a clear lead over MySQL. That says nothing about what is better for your project, but it explains why new frameworks and platforms are almost always built for PostgreSQL first.

Our benchmark: how we measured

Almost every PostgreSQL vs MySQL article quotes someone else’s benchmarks. We wanted to know what it looks like on a normal server, the kind small businesses and freelancers actually rent. So:

• Hardware: our own server with an AMD EPYC processor (Genoa generation), 12 vCPUs. Each database container was limited to 2 cores and 2 GB RAM (docker run --cpus 2 --memory 2g). That roughly matches a small cloud server like the ones we covered in our Hetzner vs netcup comparison.
• Software: official Docker images postgres:17 (17.11) and mysql:8.4 (8.4.11), Docker 29.2.1. No configuration changed. That is intentional: most databases in practice run on defaults, because nobody tunes them.
• Data: two tables generated with a fixed random seed, so identical in both databases: 100,000 customers and 2,000,000 orders (customer ID, city, amount, date). One index on customer_id.
• Repetitions: each query three times in a row; we report the range. After the first run the data was cached, so this measures the “warm” state typical of a running application.

To put it in context: this is not a lab benchmark but a practical test on shared hardware. Numbers vary by a few percent, and tuning can squeeze a lot more out of both databases. The orders of magnitude, however, are clear and repeatable.

Result 1: importing data

Both databases have a fast bulk import: PostgreSQL with COPY, MySQL with LOAD DATA INFILE. The CSV file with 2 million orders was 77 MB.

PostgreSQL imports about twice as fast. But it needs more space: 172 MB versus 120 MB for the same data. That comes from the storage layout: PostgreSQL stores a 23-byte header with version information on every row (more on MVCC below), while MySQL organizes the table as a tree around the primary key and gets by with less per-row overhead. At 2 million rows that’s 52 MB; at 2 billion rows it would be 52 GB. That matters when planning disk space and backups.

Result 2: analytical queries (the surprise)

Two typical queries you’ll find in any admin dashboard:

Query A: count and average amount per city across all 2 million orders:

SELECT city, count(*), round(avg(amount), 2)
FROM orders GROUP BY city ORDER BY 2 DESC LIMIT 3;

Query B: revenue per customer city since June, joined with the customers table:

SELECT c.city, sum(o.amount)
FROM orders o JOIN customers c ON c.id = o.customer_id
WHERE o.created >= '2026-06-01'
GROUP BY c.city ORDER BY 2 DESC LIMIT 3;

Both databases returned exactly the same results (Hamburg: 250,949 orders, average €250.50), so we really measured the same thing.

The main reason for the gap becomes visible when you ask PostgreSQL what it does with EXPLAIN: it plans “Workers Planned: 2”, splitting the query across both available cores. MySQL generally runs a single query on one core. To keep the comparison fair, we switched off parallelism in PostgreSQL (SET max_parallel_workers_per_gather = 0). Even then PostgreSQL is still 2.3 to 4 times faster. For query B, PostgreSQL also uses a hash join, while MySQL takes longer on this kind of join.

What does that mean in practice? If your project includes reports, statistics, filters over large datasets or any kind of analysis, PostgreSQL makes a noticeable difference. One second versus 200 milliseconds is something everyone notices while waiting for a dashboard.

Result 3: reading single records (a tie)

This is the normal case for any web application: “show me the orders of customer 4242”. With an index on the column, it took about one millisecond in both databases. MySQL even reported “0.00 sec”, because its built-in timer doesn’t resolve such small times.

It gets more interesting under load. We had many parallel clients issue the same kind of query, each over a normal TCP connection from outside the container:

We have to be upfront about one limitation here: the two databases were loaded with different tools: PostgreSQL with its own pgbench, MySQL with mariadb-slap (MySQL 8.4 no longer ships mysqlslap in its Docker image). The tools work similarly but not identically. So the table shows a trend, not an exact winner. The trend: with a single client PostgreSQL is clearly faster; under full load both are close. With 2 cores, the hardware simply maxes out at around 35,000 to 39,000 queries per second, whichever database you use.

For the vast majority of websites that is reassuring: an online store with a few thousand visitors a day generates a fraction of that. Neither database will be your bottleneck, as long as your indexes are right.

Result 4: writes with full durability

5,000 individual UPDATE statements, each in its own transaction (the way a web application typically writes: one click, one change):

Both ran with full durability: every committed change is flushed to disk immediately (fsync = on in PostgreSQL, innodb_flush_log_at_trx_commit = 1 and sync_binlog = 1 in MySQL). Part of the gap has a specific reason: MySQL 8.4 additionally writes a binary log by default (log_bin = 1), which is needed for replication and point-in-time recovery, and syncs it on every transaction as well. PostgreSQL has only one log, the WAL. That’s not a flaw in MySQL, just a different default. Turn off the binary log in MySQL and it gets faster, but you lose point-in-time recovery.

Result 5: memory

The difference at startup comes mainly from MySQL allocating its InnoDB buffer pool (default: 128 MB) and various internal structures immediately, while PostgreSQL allocates memory on demand. On a server with 1 or 2 GB of RAM that also runs a web server, PHP and maybe a Docker container, that’s a real argument for PostgreSQL. We wrote in detail about how to measure a server’s real memory needs (and why the numbers in top often lie) in How much RAM does a server need?.

Important: these numbers are not a verdict on efficiency under load. A production database should use a lot of RAM, because data in memory is orders of magnitude faster than on disk. In both you control that with a single setting: shared_buffers in PostgreSQL, innodb_buffer_pool_size in MySQL.

The biggest practical difference: how strict are they with your data?

MySQL’s reputation comes from a time when it silently “fixed” broken data: a value that was too large got truncated, February 30 became 0000-00-00. With default settings, that’s no longer true for MySQL 8.x. We tested it: trying to write 300 into a TINYINT column in MySQL 8.4 ended with ERROR 1264: Out of range value, and PostgreSQL rejected February 30, 2026. Both are strict by default. MySQL 8.4’s default sql_mode includes STRICT_TRANS_TABLES, NO_ZERO_DATE and ONLY_FULL_GROUP_BY.

But: many older applications and some hosts turn strict mode off, because old software won’t run otherwise. PostgreSQL has no such switch. Its strictness is not negotiable.

There are two differences that still cause trouble regularly in 2026, and we reproduced both:

Pitfall 1: case sensitivity

In MySQL 8.4 the default collation is utf8mb4_0900_ai_ci. ci stands for case insensitive, ai for accent insensitive. As a result:

-- MySQL 8.4, defaults
SELECT 'abc' = 'ABC';                                     -- 1 (true)
SELECT 'Straße' = 'strasse' COLLATE utf8mb4_0900_ai_ci;   -- 1 (true)

In PostgreSQL, 'abc' = 'ABC' is false. For case-insensitive comparisons there is ILIKE, lower() or the citext data type.

That sounds trivial but has direct consequences. We created a table with a UNIQUE column for email addresses and inserted the same address twice, once as Max@Example.com, once as max@example.com:

• MySQL: ERROR 1062: Duplicate entry 'max@example.com'. The second address is rejected.
• PostgreSQL: both rows are accepted; the table then contains 2 entries.

Which behavior is “right” depends on the case. For email addresses you usually want the MySQL behavior, which you have to build explicitly in PostgreSQL (citext or a unique index on lower(email)). For product codes or password tokens you’d rather have the PostgreSQL behavior. It gets dangerous when migrating between the two: an application that ran on MySQL for years often silently relies on WHERE email = 'MAX@example.com' also finding max@example.com. After a switch to PostgreSQL, the login page suddenly can’t find users anymore.

Pitfall 2: schema changes inside transactions

The difference we appreciate most in day-to-day work:

BEGIN;
CREATE TABLE t_ddl (a int);
ROLLBACK;

• PostgreSQL: after the ROLLBACK, the table doesn’t exist. The change has been undone.
• MySQL: the table exists anyway. CREATE TABLE (like any schema change) immediately ends the running transaction in MySQL with an implicit commit. The ROLLBACK afterwards has nothing left to roll back.

Why that matters: database migrations. If an update of your application changes ten tables and step seven fails, PostgreSQL rolls everything back and your database is in its old, working state. In MySQL, steps one to six stay applied, and you have to clean up by hand, often under time pressure while the site is down. We’ve been through both, and the PostgreSQL version is the one where you sleep better.

Architecture: processes versus threads

PostgreSQL starts a separate operating system process for each connection. That’s robust (if one connection crashes, it doesn’t take the others down) and easy to observe (you see every connection in ps), but it costs a few megabytes and some startup time per connection. That’s why PostgreSQL’s default limit is 100 connections, and why you put a connection pooler like PgBouncer in front when you have many simultaneous connections. Serverless platforms and PHP applications with many workers hit that limit quickly without a pooler.

MySQL uses one thread per connection inside a single process. New connections are cheaper, the default limit is 151, and classic PHP applications that open and close a connection for every page view feel more at home. That’s one reason the classic LAMP stack (Linux, Apache, MySQL, PHP) works so well with MySQL.

MVCC and VACUUM

Both databases allow simultaneous reads and writes without readers waiting for writers (Multi-Version Concurrency Control). But they solve it differently:

• PostgreSQL, on UPDATE, writes a new version of the row into the table and marks the old one as obsolete. A background process, autovacuum, cleans up old versions later. That has worked well on its own for many versions. On tables with extremely frequent updates you do need to keep an eye on it, otherwise the table grows (“bloat”). That also explains the larger table in our import test.
• MySQL (InnoDB) changes the row in place and stores the old version in a separate undo log. That keeps the table more compact, but very long-running transactions can make the undo log grow.

For beginners: with PostgreSQL, know that VACUUM exists and needs to run. With MySQL, know that the buffer pool is the most important setting. Neither needs more maintenance than that for a normal project.

Isolation: what does a transaction see?

PostgreSQL defaults to Read Committed: each query in a transaction sees everything others have committed up to that moment. MySQL defaults to Repeatable Read: a transaction sees a consistent snapshot from its start. Both are legitimate, but code written against one can behave differently on the other in rare cases, for instance with stock levels when two customers buy the last item at the same time. If you build something like that, lock with SELECT … FOR UPDATE in both databases instead of relying on default isolation.

Features: where PostgreSQL can do a lot more

For plain SQL basics, both are close. Beyond that, PostgreSQL has a big lead, mostly thanks to its extension system. You install an extension with a single command (CREATE EXTENSION), and it adds new data types, functions or index types to the database:

• PostGIS: geodata, distances, radius searches. The standard for anything involving maps.
• pgvector: vector search for AI applications, e.g. “find similar documents” or RAG systems. If you work with local AI and your own documents, PostgreSQL with pgvector is one of the simplest solutions because you don’t need a second database. MySQL has had a VECTOR data type since 9.0, but the ecosystem around pgvector is much further along.
• TimescaleDB: time series, such as measurements or logs.
• pg_trgm: fuzzy text search (typo-tolerant).

Plus built-in features: RETURNING (an INSERT … RETURNING id returns the new ID without a second query), arrays as a column type, custom data types, partial indexes (CREATE INDEX … WHERE active = true), exclusion constraints (for example “no two bookings for the same room in the same time slot”) and very good full-text search.

JSON in both databases

Both store JSON and both can query it. PostgreSQL has jsonb, a binary JSON type that can be made fully searchable via a GIN index. Queries like “all products whose attributes contain {"color": "red"}” are fast without you having to decide in advance which fields you’ll search. MySQL can speed up JSON fields with functional indexes and multi-valued indexes, but you have to specify up front which path to index. If you’re not sure what JSON actually is, start with What is a JSON file?.

Where MySQL has the edge

To be fair, there are areas where MySQL has advantages:

• Hosting availability: practically every shared hosting package offers MySQL or MariaDB; PostgreSQL is much rarer there. If you don’t want to run your own server, MySQL gives you more choice.
• Software compatibility: WordPress officially supports only MySQL and MariaDB. So does Shopware 6. So does Magento. If you run one of these, the PostgreSQL vs MySQL question doesn’t even arise.
• Replication for beginners: a simple primary-replica setup is quick to configure with MySQL’s built-in tools, and InnoDB Cluster and Group Replication give you a built-in high-availability solution. PostgreSQL has excellent streaming and logical replication, but automatic failover needs extra tools such as Patroni.
• Disk space: in our test MySQL used about 30 percent less space for the same data.
• Connection overhead: MySQL handles many short-lived connections better without a pooler.

Small SQL differences you’ll notice when switching

When you move from one database to the other, you almost always trip over the same points:

Most frameworks (Laravel, Django, Rails, Prisma, Doctrine) hide these differences behind their own query layer. As long as you only work through the framework, switching is often easier than expected. Hand-written SQL and stored procedures, on the other hand, need adjusting.

Ben Dicken explains the architectural differences (May 2026), especially storage layout and MVCC. A good deep dive for the sections above.

What we use ourselves (and why)

We run both databases in production, and the split isn’t ideological; it follows the software:

• PostgreSQL runs our own applications: our e-commerce framework ForkCart (as a postgres:16-alpine container, as described in our Docker Compose example) and several internal tools. It’s our default for new projects.
• MySQL or MariaDB runs where the software dictates it: Shopware and WooCommerce installations. In a Shopware installation the question never comes up.
• SQLite we use for small services with a single writer (for example our own analytics tool). It’s often the underrated third option: no separate server software, just one file.

Day-to-day, both feel uneventful. The moments we consciously miss PostgreSQL when working in MySQL are almost always the same: migrations that fail halfway, and reports that take too long.

PostgreSQL vs MySQL: which database is right for whom

Choose PostgreSQL if …

• you’re starting a new project and are free to choose,
• your application needs reports, statistics, filters or search over larger datasets,
• you want to store geodata, vector embeddings (AI), time series or complex JSON,
• data integrity and safe migrations matter more to you than minimal disk usage,
• you work with Django, Rails, Supabase, Prisma or a modern Node.js stack,
• your server has little RAM and the database shares the machine with other services.

Choose MySQL (or MariaDB) if …

• your software requires it: WordPress, WooCommerce, Shopware, Magento, many PHP applications,
• you depend on shared hosting without your own server,
• your team knows MySQL well and has no reason to switch,
• you want built-in high availability without extra tools,
• you have lots of short-lived connections and no connection pooler.

And if you’re unsure: switching is possible but takes effort. Tools like pgloader move an entire MySQL database to PostgreSQL in one command, including data types and indexes. The work is in the parts of the application that rely on MySQL behavior (see the two pitfalls above). Plan a test run with a copy of your real data, not just test data.

Checklist: PostgreSQL or MySQL in five questions

1. Does your software dictate a database? Use that one. Done.
2. Do you need analytics over lots of data, geodata or vector search? PostgreSQL.
3. Do you only have shared hosting? Probably MySQL/MariaDB, because PostgreSQL is rarely offered there.
4. How much RAM does the server have? Under 2 GB with several services: PostgreSQL is leaner at idle.
5. What does your team know? The database someone can operate at 3 a.m. during an outage is worth more than ten percent of speed.

For your own server to experiment on, a small VPS is enough. Both databases run there as Docker containers in under a minute, exactly as in our test.

Frequently asked questions about PostgreSQL vs MySQL

Is PostgreSQL faster than MySQL?

For analytics over many rows, yes: three to seven times in our test (with parallelism), still two to four times without it. For single records via an index, both are about equally fast (around 1 ms). For individual write transactions, PostgreSQL was about three times faster in our test, partly due to MySQL’s binary log being enabled by default. For a normal website, neither will be the bottleneck.

Is PostgreSQL harder to learn than MySQL?

No. Over 90 percent of the SQL is the same. PostgreSQL is stricter about errors, which means a few more error messages at first but fewer hidden problems later. The psql command line has its own shortcuts (\dt for tables, \d table for structure) that you learn in fifteen minutes.

Are MySQL and MariaDB the same?

Not entirely anymore. MariaDB was forked from MySQL in 2009 and was a drop-in replacement for a long time. Today there are differences, for example in JSON handling, system variables and some SQL functions. For WordPress, Shopware and most PHP applications they’re interchangeable. Most statements in this article apply to both when compared with PostgreSQL.

Which database is better for beginners?

If you’re starting with WordPress or a PHP shop system: MySQL, because you’ll need it anyway. If you’re learning to program and building your own application: PostgreSQL, because it trains you early on to keep data clean, and because most current tutorials and frameworks use it.

Are PostgreSQL and MySQL free?

Yes, both. PostgreSQL is under a permissive license with no commercial edition. MySQL Community Edition is under GPLv2 and free. Oracle additionally sells MySQL Enterprise Edition with support and extra features. You don’t need it to run a normal web application.

Can I switch from MySQL to PostgreSQL?

Yes. pgloader transfers the data itself automatically in most cases. The effort is in the application: hand-written SQL with backticks, AUTO_INCREMENT, ON DUPLICATE KEY UPDATE, and above all code that relies on MySQL ignoring case in comparisons. Test with a copy of your real data.

Which database uses less memory?

At idle, PostgreSQL: 24 MB versus 424 MB right after startup in our test. Under load, settings (shared_buffers and innodb_buffer_pool_size) determine usage. In production, both should deliberately get a large share of RAM, because that makes queries faster.

Which database uses less disk space?

MySQL. Our 2 million orders took 120 MB including the index in MySQL and 172 MB in PostgreSQL. The reason is PostgreSQL’s row header, which holds version information for MVCC.

Which is better for WordPress?

MySQL or MariaDB. WordPress doesn’t officially support any other database. There are plugins that connect PostgreSQL or SQLite, but many plugins write their own MySQL-specific SQL and won’t work reliably.

Which is better for AI applications?

PostgreSQL with the pgvector extension. It lets you store texts, regular data and the vectors for semantic search in a single database. That saves you a separate vector database and is usually more than enough for small and medium projects.

What do large companies use?

Both. MySQL was the backbone of many large web platforms in the 2000s and 2010s, and many still run on it today. Newer platforms and cloud services strikingly often choose PostgreSQL or PostgreSQL-compatible systems. For your decision, though, that matters less than which software you want to run.

Conclusion

In 2026, PostgreSQL vs MySQL is no longer a matter of faith but of use case. The old prejudices no longer hold: MySQL no longer swallows broken data by default, and PostgreSQL isn’t complicated. In our own test on a small 2-core server, PostgreSQL was three to seven times faster at analytics, twice as fast at importing and about 400 MB leaner at idle. MySQL was nearly on par for single queries under full load and needed about 30 percent less disk space.

Our recommendation: new projects on PostgreSQL. Existing projects and everything around WordPress, Shopware and Magento stay on MySQL or MariaDB. And if you haven’t looked at it yet: for small services, consider SQLite too. A direct SQLite vs PostgreSQL comparison is next on our list.