Postgres vs MySQL: Differences and How to Choose
18 min read
Key takeaways
Both are free, mature relational databases, and either one can run most web apps. Pick PostgreSQL if you want schema changes you can roll back, a full outer join, materialized views or the six index types its manual lists. Pick MySQL if your team, tools or hosting already run on it, because switching costs more than it looks.
Which one is faster? We found no neutral, linked benchmark, so test your own queries.
- Money first: PostgreSQL is free under a BSD or MIT style licence. MySQL Community Edition is free under the GPL version 2, and Oracle sells commercial editions.
- In MySQL
8.4, the default storage engine is InnoDB, which gives transactions that follow ACID (atomicity, consistency, isolation and durability, explained below). The old line that MySQL isn't fully ACID only applies if you pick another engine. - PostgreSQL can undo a schema change inside a transaction. MySQL
8.4makes each schema change atomic, but it's not transactional, and it ends any open transaction first. - MySQL's join syntax lists no full outer join. PostgreSQL's does.
- MySQL's own manual says it has no materialized views. PostgreSQL has them.
- For JSON, PostgreSQL has a binary
jsonbtype that can be indexed directly. MySQL indexes JSON through a generated column. - We found no neutral, linked benchmark that says one is faster. Stack Overflow's 2025 survey shows more respondents reporting extensive development work with PostgreSQL, but it measures popularity.
Every fact below comes from the PostgreSQL and MySQL manuals, project pages or a named survey, read on October 8, 2026, with the page linked beside the claim. We did not run either database.
Last reviewed October 2026.
Postgres vs MySQL at a glance
Each cell links to its source.
| PostgreSQL | MySQL | |
|---|---|---|
| Who runs it | Community project, copyright held by the PostgreSQL Global Development Group | Developed by Oracle |
| Licence | PostgreSQL License, similar to BSD or MIT | Community: GPL version 2. Enterprise: commercial |
| Versions we found (Oct 2026) | 14 to 18 supported, 19 in beta | Download page lists 26.7.0, 9.7.2 LTS, 8.4.11 LTS and 8.0.46; 8.0 is in Sustaining Support |
| Default table engine | Not applicable | InnoDB, with other engines available |
| Concurrency model | MVCC: readers do not block writers | InnoDB: row-level locks, consistent reads and MVCC |
| Schema changes (DDL) | Can run inside a transaction | Atomic, but ends the open transaction |
| Full outer join | Supported | Join syntax lists none |
| Materialized views (saved query results) | Supported, refreshed with REFRESH MATERIALIZED VIEW | Manual FAQ answer: "No." |
| JSON | json and jsonb types, jsonb can be indexed | JSON type, indexed through a generated column |
| Index types | Six types, B-tree by default, plus the bloom extension | B-tree and hash described |
| Replication | Streaming, cascading and synchronous options documented | Asynchronous by default, with semisynchronous and Group Replication |
| Reported extensive development work with (Stack Overflow 2025) | 55.6% of all respondents | 40.5% of all respondents |
On price, there's nothing to split here. Both Community editions are free, so what you pay for is hosting, staff time and, for MySQL, optional Enterprise features.
On Oracle's store page, a MySQL Enterprise Edition subscription is listed from US$5,350 for a 1 to 4 socket server (read October 8, 2026). It doesn't say what that price range covers, so ask Oracle for a quote.
So, what is each one?
PostgreSQL is, in the project's own words, an open-source database that uses and extends SQL. Its history goes back to 1986, and the project calls its licence "liberal", similar to the BSD (Berkeley Software Distribution) or MIT (Massachusetts Institute of Technology) licenses.
Both are short, permissive open-source licences. Read the real text before you rely on our summary.
The project's versioning page lists versions 14 to 18 as supported, with 18 the current one, first released on September 25, 2025. PostgreSQL 14 gets its final release on November 12, 2026. PostgreSQL 19 Beta 4 came out on September 24, 2026, but it's not a final release yet.
MySQL is developed by Oracle. The Community release comes under version 2 of the GNU (GNU's Not Unix) General Public License (GPL, a licence that requires derived software to stay open), with extra permissions. Oracle also sells commercial editions.
Two release tracks exist, says MySQL's manual: LTS (long-term support) and Innovation.
The download page lists versions 26.7.0, 9.7.2 LTS, 8.4.11 LTS and 8.0.46.
Oracle's notice says that as of April 21, 2026, MySQL 8.0 is under Sustaining Support, and it encourages a move to 8.4 LTS or 9.7 LTS. So if an older comparison treats 8.0 as the version to pick, that page is out of date.
Transactions and ACID: does the old advice still hold?
ACID stands for atomicity, consistency, isolation and durability. You've probably heard that MySQL isn't "really" ACID. In plain terms, ACID means a group of changes either all happen or none do, and a committed change survives a crash.
Older comparison pages say MySQL is ACID only with some engines.
That's still true for engines that aren't transactional. MySQL's manual lists InnoDB and NDB (the engine behind MySQL's clustered edition) as the transactional engines among its built-in ones, and MyISAM, MEMORY (a RAM-based engine) and Archive as not transactional. An engine is the part of MySQL that stores and reads table data.
What changed is the default. In MySQL 8.4, InnoDB is the default engine, so a CREATE TABLE without an ENGINE clause gives you an InnoDB table. Its manual says InnoDB operations follow the ACID model, with commit, rollback and crash recovery.
You'd only lose that by choosing another engine on purpose.
Concurrency: how each handles many users
When a hundred people hit your app at once, both databases rely on MVCC, short for multi-version concurrency control. It keeps more than one version of a row so that readers and writers can work at the same time.
PostgreSQL's manual says each statement sees a snapshot of the data. So a reader doesn't wait for a writer, and a writer doesn't wait for a reader (the vacuum section below explains why old row versions are kept). MySQL's InnoDB manual says it uses row-level locking and consistent reads, and lists MVCC as supported.
Some pages boil this down to a rule of thumb that MySQL is better for reads and Postgres for writes. Neither manual makes that claim as a measured result, so test your own workload.
Schema changes: the difference that bites in production
Picture a migration that dies halfway through. DDL means data definition language, the commands that change structure, such as adding a column.
The PostgreSQL project's wiki says PostgreSQL can perform transactional DDL. That means you can start a transaction, change a table, spot your mistake and roll everything back. One caveat: the wiki page was last edited in June 2012, so treat it as a description of a long-standing feature and test your own version.
MySQL 8.4 supports atomic DDL, so a single statement either fully succeeds or fully rolls back, even if the server stops partway. Its manual says atomic DDL is not transactional DDL. A DDL statement implicitly commits any open transaction first, so it can't sit inside one.
MySQL 8.4 Reference Manual, atomic DDL page, October 2026.
If your team ships lots of database migrations (scripted schema changes), this matters. In PostgreSQL, a failed migration can be wrapped so nothing is half applied. In MySQL, you plan around it, with smaller steps and backups.
SQL features and standards
PostgreSQL's SQL Conformance appendix says it supports most major features of SQL:2023 and conforms to at least 170 of the 177 mandatory Core features. It also notes that no current database claims full Core conformance.
PostgreSQL manual, SQL Conformance appendix, October 2026.
The clearest gap we could confirm is joins.
The join syntax in MySQL's manual lists INNER, CROSS, LEFT, RIGHT, NATURAL and STRAIGHT_JOIN joins, and no full outer join. PostgreSQL's select command reference lists a full outer join.
We didn't compare every other SQL feature.
Data types, JSON and indexes
Odds are your app stores some JSON (JavaScript Object Notation, a text format for nested data) next to normal columns. Both databases can handle it, but they index it differently.
PostgreSQL offers two JSON types. Its manual says json keeps an exact copy of the input text, while jsonb is stored in a binary format that's faster to process. And jsonb also supports indexing.
MySQL has one JSON type that validates documents and stores them in an internal binary format. Its 8.4 manual says JSON columns aren't indexed directly. Instead, you index a generated column that pulls out one value.
InnoDB also supports multi-valued indexes on JSON arrays.
PostgreSQL manual, JSON Types page, October 2026.
Indexes are the other place the manuals part ways. PostgreSQL lists six types, and B-tree is the default.
The others are Hash, GiST (Generalized Search Tree) and Space-Partitioned GiST. Then come GIN (Generalized Inverted Index, for values with many parts such as arrays) and BRIN (Block Range INdex, which summarizes ranges of table blocks).
A bloom extension is also named for PostgreSQL. MySQL's index page describes B-tree and hash indexes, and says hash indexes serve only equality tests.
PostgreSQL manual, Index Types page, October 2026.
A longer list doesn't make a database faster for you, and the pages we read don't compare the two on index choice. You only gain if your queries actually need one of these types, such as for arrays or very large tables.
Views, extensions and replication
A materialized view stores the result of a query so that a report does not rerun it each time. PostgreSQL supports them and refreshes them with REFRESH MATERIALIZED VIEW. The MySQL 8.4 manual's views FAQ asks whether MySQL has materialized views and answers "No."
MySQL 8.4 Reference Manual, Views FAQ, October 2026.
PostgreSQL also packages add-on features as extensions. Its manual says a package of related SQL objects is called an extension, and one CREATE EXTENSION command loads it. We didn't check MySQL's plugin system line by line, so we make no claim about it.
For copies of the database used for failover or reads, MySQL's manual says replication is asynchronous by default, and it also documents semisynchronous replication, delayed replication and Group Replication.
PostgreSQL's high availability chapter describes synchronous and asynchronous options and lists streaming, cascading and synchronous replication. Both have built-in replication, so on its own it's not the deciding factor.
Housekeeping and limits of each
Each database has chores.
PostgreSQL's chore is VACUUM. An update or delete does not remove the old row version at once, because other transactions may still need it. VACUUM reclaims that space, updates planner statistics and guards against transaction ID wraparound.
Autovacuum, a background helper that runs VACUUM for you, is on in the default configuration. For many installs, that's enough.
MySQL's trade-offs are different. Its join syntax lists no full outer join, its views FAQ says no materialized views, and its schema changes commit the open transaction.
The pages we read don't describe a matching routine chore, so check its manual for your engine. Oracle also sells paid editions with extra features, priced above.
Neither list rules one out; use them as a checklist against your team's habits.
Where each fits
- Choose PostgreSQL if you need schema changes that roll back, a full outer join, materialized views or its six documented index types, per the sources in the table below.
- Choose MySQL if your team, tools and hosting already run on it, you rely on Oracle support, or a vendor product you depend on is built for it.
| Your situation | Lean toward | Why, with the source |
|---|---|---|
| New project, no existing database | PostgreSQL, unless a tool you need targets MySQL | Rollback of schema changes and full outer join |
| Already run MySQL well | MySQL | Switching cost is real, and Oracle's download page lists 8.4 LTS |
| Heavy use of migration scripts | PostgreSQL | DDL can sit inside a transaction (first row) |
| Reports that reuse slow queries | PostgreSQL | Materialized views exist, and MySQL's manual says it has none |
| Lots of JSON you want to search | Test both | jsonb is indexable directly, and MySQL can index through generated columns |
| Need Oracle vendor support | MySQL | Oracle sells commercial MySQL editions |
| Worried about "not ACID" | Either | InnoDB is the default in 8.4 |
Running version 8.0 or PostgreSQL 14 | Plan an upgrade | MySQL 8.0 is in Sustaining Support, PostgreSQL 14 ends November 12, 2026 |
Answer five quick questions to narrow it down.
Which database fits you?
Question 1 of 5
Where are you starting from?
Moving a working system has real costs, so your current setup counts.
Performance: what we can (and can't) say
Pages that rank for this topic often say MySQL is faster for simple reads and PostgreSQL is faster for complex queries. The top-ranking pages we read in October 2026 had no linked benchmark behind those claims.
We won't repeat a speed figure, and we won't offer our own number either, because we ran no tests.
A test on your own data is cheap and more reliable. Take your ten slowest real queries and your busiest write path. Run them on both databases on the same hardware with your real data size, then compare.
Common myths, checked against the manuals
Repeated claims we could check against the manuals.
- Myth: MySQL is not ACID. Wrong for the default engine in
8.4, where InnoDB follows the ACID model. Right only for non-transactional engines such as MyISAM. - Myth: PostgreSQL follows the SQL standard fully. Close, but no. Its own manual says at least 170 of 177 mandatory Core features, and that no current database claims full Core conformance.
- Myth: MySQL
8.0is the version to pick. Not anymore. As of April 21, 2026 it is in Sustaining Support. - Myth: one of them is clearly faster. Nobody showed us a linked benchmark that says so.
- Myth: PostgreSQL has no cost. The software is free. Hosting, backups, upgrades and staff time are not.
What we couldn't source
On the pages we could read, we didn't find what Oracle's store price range for MySQL Enterprise Edition covers, a neutral benchmark, or a side-by-side of every SQL feature.
We also left out data types, extensions, full-text search and JSON handling. Both databases cover these in their manuals, and the details change from version to version. If one of them could decide your choice, read that chapter for the exact version you plan to run.
How to test both on your own data
Most teams can do this in a day or two.
- Load a copy of your real data, at your real size, into both databases on the same hardware.
- Pick your ten slowest queries and your busiest write path, and run them on each one.
- Run your real schema changes, then try to roll back a failed one in each database.
- Write down the version numbers you tested, and check them against the support dates above.
- Ask who on your team can fix each one at 3 a.m. (count that as a result too).
Popularity and ecosystem
On adoption, the 2025 Stack Overflow Developer Survey shows 55.6% of all respondents reporting extensive development work with PostgreSQL and 40.5% with MySQL.
It's a survey of developers who chose to answer it. So it shows what people work with and says nothing about speed or safety.
Copying data out for analytics
Sooner or later, someone asks you to copy the database into a data warehouse or lakehouse. Both databases can feed that, using the change log each one already keeps.
For PostgreSQL, change capture uses logical decoding and replication slots. MySQL tools read its binary log. Either way, this is change data capture (CDC), which means copying only the changes.
OLake Go is an open-source tool that runs a full load and then change capture for Postgres and MySQL. For Postgres (version 10 or above) it uses the pgoutput plugin with a replication slot and a publication. For MySQL (version 5.7 or above) it reads the binary log in row format, and MariaDB works as a CDC source too. Both connectors also offer incremental sync. OLake Go writes Apache Iceberg tables or Parquet files to object storage such as S3, MinIO or GCS. See the OLake documentation for connector details and limits.
Q1. Is Postgres better than MySQL?
Q2. Is Postgres faster than MySQL?
Q3. Is MySQL ACID compliant?
Q4. Is PostgreSQL free for commercial use?
Q5. Which is easier to learn?
Q6. Can I roll back a schema change in MySQL?
Q7. Does MySQL have materialized views?
Q8. Which handles JSON better?
Q9. Which is more popular?
Conclusion
Starting fresh: choose PostgreSQL if you want rollback-safe schema changes and a full outer join.
Already live on MySQL with tooling built around it: stay, unless the switch would save you more than it costs.
Check your version first. MySQL 8.0 is in Sustaining Support and PostgreSQL 14 reaches its final release on November 12, 2026, so an upgrade plan comes first. Then test your own queries, because no linked benchmark we found will decide it for you.
