PostgreSQL vs MySQL: Picking a Database for Your Site

The database you pick on day one is the one you live with on day 400. Not because migrating is impossible. It isn’t. But migrations cost weeks you could have spent shipping.

So let’s skip the abstract feature tour. This is a decision guide built around project type. The question is what you’re actually building, and which engine fits it.

Two names dominate the conversation. PostgreSQL and MySQL. Both are mature, both are free to start with, and both will run a website just fine. The differences show up in specific places, things like JSON handling, concurrency behavior, licensing, and how painful it is to move between them later.

One note on vocabulary before we go further. When I say MVCC, I mean multi-version concurrency control, the mechanism that lets readers and writers work at the same time without blocking each other. It’s the reason your analytics query doesn’t freeze your checkout page. That’s the whole concept.

PostgreSQL vs MySQL at a Glance

That table is only the summary. The rest of this article does the explaining.

What Is PostgreSQL?

PostgreSQL is an open-source relational database that has been in development since the 1980s and has spent the last decade becoming the default choice for teams that expect to do non-trivial things with their data.

The current major version is PostgreSQL 17, released on September 26, 2024. Two things in that release matter for practical workloads. It cuts vacuum memory usage by up to 20x through a new internal memory structure, and it adds SQL/JSON features including JSON_TABLE().

Vacuum, in plain terms, is PostgreSQL’s background cleanup process. It reclaims space from deleted or updated rows. It has historically been the operational chore people complain about. Reducing its memory footprint by up to 20x makes it less of a chore on smaller instances.

The other thing to know is that PostgreSQL is distributed under the PostgreSQL License, a permissive BSD-style license. Free commercial and non-commercial use, modification, and redistribution, with only a copyright-notice requirement. No fee, and no obligation to release your changes.

That last clause matters more than people realize, and we’ll come back to it.

What Is MySQL?

MySQL is an open-source relational database that became the default because it was fast, simple, and bundled into nearly every shared host and VPS stack and CMS platform on the planet.

The version to know right now is MySQL 8.4, released in April 2024 as the first release under Oracle’s new Long-Term Support model. LTS releases get 5 years of premier support plus 3 years of extended support, with a new LTS roughly every 2 years.

Between LTS releases, Oracle ships quarterly “Innovation” releases. Those carry the 9.x version numbers and include new features, but with shorter support windows than LTS. They are not a stable successor line. They’re the preview track that feeds the next LTS. If you’re running a production site, you want the LTS track.

Licensing is the other thing to understand here. MySQL Community Edition is GPL-licensed. If you distribute a modified version, you must release your changes under a GPL-compatible license. Oracle separately sells commercial licenses so companies that want to embed MySQL without that share-alike obligation can do so for a fee.

If you’re running a website and never distributing the database itself, GPL doesn’t bite you. If you’re shipping a product with MySQL embedded inside it, it might.

Key Differences Between PostgreSQL and MySQL

ACID and MVCC

Both databases are ACID-compliant (atomic, consistent, isolated, durable). Transactions either complete fully or roll back cleanly.

The difference is in the defaults and the depth. MySQL’s ACID guarantees apply to InnoDB, which has been the default storage engine for years, so in practice you get them without thinking about it. PostgreSQL treats transactional integrity as a baseline assumption of the whole system, independent of which storage engine you use.

Both use MVCC. The practical consequence is that on either engine, a long-running read query doesn’t block writes to the same table. Where they diverge is in how aggressively each one handles contention under heavy concurrent writes. PostgreSQL tends to handle complex multi-statement transactions with more predictable behavior, while MySQL’s InnoDB is extremely well-optimized for high-throughput simple operations.

JSON Support

This is where the gap is widest, and where it matters most for modern web apps.

MySQL has a native JSON type and it works. You can store a JSON document, query into it, and index specific paths via generated columns. That means you create a real column that extracts a value from the JSON, then index that column normally.

PostgreSQL has both JSON (stored as text) and JSONB (stored in a decomposed binary format). JSONB is the one you want. It’s indexable directly with GIN indexes, which means you can query arbitrary keys inside a document efficiently without pre-declaring which paths you care about.

The practical consequence is that if your data model is mostly relational with occasional JSON fields, MySQL is fine. If you’re storing semi-structured data and querying it in ways you haven’t fully predicted yet (event payloads, webhook bodies, referral metadata), PostgreSQL’s JSONB gives you room to change your mind without a schema migration.

Indexing

MySQL gives you B-tree indexes, hash indexes, full-text indexes, and spatial (R-tree) indexes. That covers the overwhelming majority of web application needs.

PostgreSQL gives you all of that plus four more. Here is what each one does.

GIN

Indexing composite values like JSONB documents and arrays.

GiST

Geometric and range data.

BRIN

Very large tables where data is naturally ordered. Tiny compared to a B-tree.

SP-GiST

Non-balanced structures like quadtrees.

You don’t need those index types on day one. You need them on day 300, when someone asks for a feature that requires a query shape your current indexes can’t serve.

Performance: When Each Database Wins

Neither database “wins” performance in general. They win different workloads. Your choice affects how you’ll optimize website speed and backend efficiency later.

MySQL tends to win on read-heavy, simple-query workloads. A CMS serving cached-ish page requests, a blog, a product catalog where most queries are single-table lookups by primary key. MySQL’s InnoDB is exceptionally well-tuned for that shape. It’s why it ended up powering so much of the web. The trade-off is that as query complexity grows (multiple joins, subqueries, window functions), the optimizer has less room to help you.

PostgreSQL tends to win on complex queries and high-concurrency write workloads. Its query planner handles multi-table joins, CTEs, and analytical queries with more sophistication. Its MVCC implementation handles concurrent writes with more predictable behavior under contention. The trade-off is that for a simple SELECT * FROM posts WHERE id = 5, you’re not gaining anything, and you may be paying slightly more in per-connection overhead if you’re not using a connection pooler.

Two concrete conditions to decide by:

• If your queries are mostly single-table lookups and your write volume is moderate, MySQL is the lower-friction choice.
• If your queries involve three or more joins, aggregations, or window functions, and you expect concurrent writes, PostgreSQL will save you from fighting the optimizer later.

Neither statement is absolute. Both databases will run both workloads. The question is which one you’ll be fighting less in eighteen months.

Which Database for Which Project Type?

Here’s the decision list. Find your project.

WordPress, Drupal, Joomla, or any mainstream CMS → MySQL. These platforms are built and tested against MySQL first, so ecosystem fit matters more here than any theoretical performance edge. Their plugins, migration tools, and hosting stacks assume it. When you’re ready to publish your WordPress site, you’ll benefit from that deep ecosystem support. You can run WordPress on PostgreSQL, and people do, but you’re signing up for compatibility friction that buys you nothing on a content site.

Standard e-commerce on a mainstream platform (WooCommerce, Magento) → MySQL. Same reasoning. The ecosystem is MySQL-shaped.

Analytics, reporting, and dashboards → PostgreSQL. Window functions, CTEs, and the query planner’s ability to handle multi-table aggregation are the difference between a report that runs and a report that times out. This is the workload PostgreSQL was built for.

Referral and affiliate tracking → PostgreSQL. This is a specific case worth calling out because it’s the workload behind most of what I write about. Tracking systems take a high volume of concurrent writes (click events, conversions, attribution records) and then run complex attribution queries across them. When a traffic spike hits—a promotional campaign or holiday season driving a sudden surge of concurrent click and conversion writes—a simpler setup starts showing contention and lock timeouts, but PostgreSQL’s MVCC behavior handles the burst predictably while the planner still runs your attribution queries efficiently. That’s the exact combination of concurrent writes plus complex reads where PostgreSQL pays off. You also get JSONB for storing unpredictable event metadata without schema migrations every time a new tracking parameter shows up.

API-first SaaS backends → PostgreSQL. Multi-tenant data models, complex permission queries, JSONB for flexible per-tenant configuration, and ON CONFLICT for idempotent writes. It’s the default for a reason.

Simple CRUD apps with predictable access patterns → either, lean MySQL. If your schema is stable, your queries are simple, and your team already knows MySQL, there’s no compelling reason to switch. Familiarity is a real engineering asset.

Projects with unpredictable data shapes → PostgreSQL. If you don’t yet know what your data looks like, JSONB lets you store it now and normalize it later.

PostgreSQL vs MySQL in the Cloud

Both databases are first-class citizens on every major managed platform, so this rarely decides the choice on its own. Whether you choose managed VPS hosting or serverless platforms, both PostgreSQL and MySQL support is available.

AWS RDS offers managed PostgreSQL and managed MySQL side by side, with the same operational surface, automated backups, replication, and failover handled for you.

Google Cloud SQL does the same, offering managed PostgreSQL and managed MySQL, both fully supported.

PlanetScale is worth naming separately because it’s a different shape of product. It’s a MySQL-compatible serverless platform known for database branching workflows. You can spin up a branch of your schema the way you’d branch code, test a migration against it, and merge it. If your team already thinks in git branches, that workflow maps cleanly onto how you’d want to handle schema changes.

One note: PlanetScale speaks the MySQL wire protocol without being the MySQL database itself. That’s the same relationship MariaDB has, and it’s worth understanding before you commit.

For most teams, the managed platform question comes down to operational preference, since the capability on both sides is roughly equal. Pick the one your team already has infrastructure in.

Should You Use MariaDB Instead of MySQL?

MariaDB is a MySQL-compatible fork, close enough in practice that most apps can’t tell the difference. It speaks the same wire protocol and the same SQL in most common usage. If your app runs on MySQL, it will very likely run on MariaDB unchanged.

The history matters because it explains why the fork exists. MariaDB was forked from MySQL on October 29, 2009 by MySQL’s original creator, Michael “Monty” Widenius, before Oracle had even finished acquiring Sun Microsystems, which owned MySQL at the time. The fork was driven by concern that Oracle’s ownership could change MySQL’s licensing or its openness.

MariaDB exists because the person who wrote MySQL didn’t trust where it was heading.

Should you use it? It depends on one condition, whether you need features MySQL has added since the fork, or whether you want a database whose governance isn’t tied to a single vendor.

• If you’re running a standard CMS or web app, MariaDB is a drop-in replacement and many Linux distributions ship it as the default “MySQL.”
• If you need MySQL 8.x-specific features, like the row-alias upsert syntax below, check compatibility before assuming MariaDB supports them identically.
• If your concern is licensing risk, MariaDB’s independence is the point.

For most web projects, either works, and the choice comes down to what your host provides.

Migrating from MySQL to PostgreSQL

You can migrate. It’s a real project that takes real planning time. If you’re managing your own infrastructure, understanding server administration costs becomes important during migration. Here are the three things that actually break.

Data type mismatches. MySQL’s TINYINT(1) is how booleans are usually stored; PostgreSQL has a real BOOLEAN type. MySQL’s DATETIME and PostgreSQL’s TIMESTAMP behave differently around time zones. Unsigned integers exist in MySQL and don’t in PostgreSQL. You’ll be writing conversion logic, and you’ll find edge cases in production data that your test data didn’t have.

AUTO_INCREMENT vs SEQUENCE. MySQL uses AUTO_INCREMENT on a column. PostgreSQL uses a SEQUENCE object, usually wired up via the SERIAL or IDENTITY column types. The gotcha is that a straight dump and restore doesn’t carry the increment state the same way. Your data lands, but the sequence is still sitting at 1, so the next insert collides with an existing primary key. You need explicit sequence resets after the restore. This is a frequent migration oversight.

Case sensitivity. This is a real migration gotcha that deserves real attention. MySQL’s identifier case sensitivity for table names (note: column names are always case-insensitive in MySQL) depends on the server system variable lower_case_table_names. On Linux, the default is lower_case_table_names=0, making table names case-sensitive. On Windows and macOS, the default is lower_case_table_names=1 or 2, making table names case-insensitive. If your MySQL schema was built on Windows with inconsistent table-name casing (e.g., Users and users as separate tables), that schema will break when migrated to Linux MySQL or to any other database expecting case-sensitive table names. PostgreSQL behaves differently. Unquoted identifiers are automatically folded to lowercase, so unquoted UserID and userid refer to the same table or column. PostgreSQL is only case-sensitive when identifiers are double-quoted (e.g., "UserID" and "userid" are two different objects). This makes PostgreSQL’s behavior more predictable for incoming MySQL schemas, as long as you don’t rely on quoted identifiers for case-sensitive separation.

Here’s the upsert syntax difference, since upserts are where most application code touches the database directly:

“`sql — MySQL 8.4 (row-alias form; the older VALUES(col) form is deprecated since 8.0.20) INSERT INTO accounts (email, last_seen) VALUES (‘user@example.com’, NOW()) AS new ON DUPLICATE KEY UPDATE last_seen = new.last_seen;

— PostgreSQL 17 INSERT INTO accounts (email, last_seen) VALUES (‘user@example.com’, NOW()) ON CONFLICT (email) DO UPDATE SET last_seen = EXCLUDED.last_seen; “`

Two structural differences to notice. MySQL infers the conflict target from whatever unique key you violated. PostgreSQL requires you to name it (ON CONFLICT (email)), which is more explicit and catches mistakes earlier. And PostgreSQL exposes the proposed row through a special EXCLUDED pseudo-table, while MySQL’s modern form uses a row alias you declare inline.

If you use the deprecated VALUES(col2) form in MySQL, it still works but you’re building on a deprecated path. Use the row alias.

Conclusion: Which Database Should You Choose?

Pick by the shape of your workload and constraints instead of a single feature benchmark.

Default to MySQL 8.4 LTS for CMS platforms, WordPress, and standard e-commerce. The ecosystem assumes it, your host supports it, and you gain nothing by swimming against that current. Default to PostgreSQL 17 when you have complex analytics or reporting queries, concurrent write bursts that need predictable behavior, or data that’s still taking shape and you want to store it as JSON without schema migrations. For straightforward CRUD on a stable schema where your team already knows MySQL, stay there. Familiarity is a real engineering asset.

Considering MariaDB? It’s a genuine MySQL-compatible fork with independent governance. Check feature compatibility first, then decide based on what your host offers.

And if you’re already on one and thinking about the other, budget for the migration properly. Data types, sequences, and case sensitivity each cost you a day you didn’t plan for.

Frequently Asked Questions

Is PostgreSQL better than MySQL?

Not universally. They excel at different workloads. PostgreSQL handles complex queries, concurrent writes, and unpredictable data shapes better. MySQL is simpler and faster for straightforward read-heavy applications. The question is which fits your specific project, not which is categorically “better.”

Can I migrate from MySQL to PostgreSQL without downtime?

Migrations typically require planned downtime or a dual-write cutover window. Data types, auto-increment state, and case-sensitivity rules need careful re-mapping. The auto-increment-to-sequence reset, in particular, catches teams off guard because straight dump-and-restore leaves the sequence sitting at 1, causing primary-key collisions on new inserts.

Does WordPress support PostgreSQL?

WordPress is tested and optimized for MySQL first. You can technically run WordPress on PostgreSQL with plugins, but you gain compatibility friction that buys you nothing on a content site. Stick with MySQL unless you have a specific reason to diverge from the ecosystem.

Is MariaDB the same as MySQL?

MariaDB is a MySQL-compatible fork created by MySQL’s original author. It speaks the same wire protocol and works as a drop-in replacement for most applications. The difference is governance. MariaDB is independent, while MySQL is owned by Oracle. For standard web projects, either works; check compatibility if you need MySQL 8.x-specific features.

Thank you for reading!

Roosevelt Naylor

Editor

Roosevelt Naylor writes about referral programmes and word-of-mouth growth on Limitless Referrals: what actually makes someone recommend a business, and why most reward schemes never manage it. He prefers plain arithmetic to growth-hacking claims.