PostgreSQL vs MySQL in 2025: Technical Choice or Force of Habit?

"PostgreSQL or MySQL?" — this question comes up in job interviews, gets debated at conferences, and sparks arguments in article comments. In 2025, PostgreSQL leads MySQL in developer popularity (45.55% vs 41.09%), wins "DBMS of the Year" awards, and is considered the more "advanced" choice. But MySQL still runs on billions of installations, remains the first choice for WordPress and Laravel, and companies like Uber preferred it over PostgreSQL.

So what's the deal? Is this a technical choice based on real advantages, or just habit and ecosystem inertia?

Spoiler: reality is more complex than "PostgreSQL is better at everything."

Performance: The Benchmark Wars

Google "PostgreSQL vs MySQL performance" and you'll get contradictory results. Some tests show PostgreSQL is 4.7 times faster than MySQL. Others say the difference is at most 30% and depends on specific workload. Still others claim MySQL is faster for read operations.

The truth is that performance depends on hundreds of factors: database version, configuration, hardware, query patterns, indexes, data schema. A test showing PostgreSQL's fivefold advantage in financial transactions might show the opposite result on a read-heavy web application.

Recent research on identical hardware and configurations showed: for simple SELECT without conditions, PostgreSQL is 10-15% faster. For SELECT with WHERE, PostgreSQL is roughly 10 times faster. For INSERT, the difference is minimal. But these are all synthetic tests on simplified data.

In the real world, the truth is more boring. As experts note: "For most workloads, PostgreSQL and MySQL performance is comparable with at most 30% variation. On the other hand, if your query misses an index, it could be 10-1000x degradation regardless of which database you choose."

Simply put: proper indexes, optimized queries, and adequate configuration matter more than choosing between PostgreSQL and MySQL. If your application is slow, the problem is likely not that you chose the "wrong" database.

MySQL Still Faster for Reads

This isn't a myth. MySQL with InnoDB and proper caching configuration is indeed faster at handling read-heavy workloads. This is precisely why WordPress, Drupal, and popular CMS platforms continue using MySQL as the default database. For a blog serving 10,000 page views per minute and 10 writes per hour, MySQL shows excellent results.

PostgreSQL wins at complex queries. Window functions, recursive CTEs, complex JOINs with subqueries — here PostgreSQL's query optimizer shows its superiority. If your application builds complex analytics, aggregations across multiple tables, PostgreSQL can be an order of magnitude faster thanks to better query plan optimization.

The Uber Story: When PostgreSQL Didn't Scale

In 2016, Uber published a detailed breakdown of their migration from PostgreSQL to MySQL. The article sparked heated discussion in the community, and many accused Uber of bias. But let's look at the facts.

Uber's problems with PostgreSQL were real. They used PostgreSQL 9.2 (ancient even by 2016 standards) and faced write amplification. Every row update created a new version and required updating all indexes. Uber had tables with hundreds (!) of indexes. Updating one field generated massive write operations.

Replication was also painful. PostgreSQL 9.2 used physical replication through WAL, which logged every change at the disk page level. Replication data volume was enormous, version upgrades required downtime, cascade replication was complex.

MySQL with InnoDB solved these problems more elegantly. Secondary indexes store a reference to the primary key, not to the physical location of the row on disk. When updating a field that's not in an index, that index isn't touched at all. Logical replication through binlog is more compact and flexible.

But here's important context: many of Uber's problems are solved in modern PostgreSQL versions. Logical replication appeared in PostgreSQL 10. Tools like pg_rewind simplified failover. Hot Standby allows queries on replicas to work simultaneously with replication. Data corruption problems are minimized.

Write amplification with many indexes remains. But the question is: are hundreds of indexes on one table even necessary? Critics fairly note: "Why do you have so many indexes? Do you really query on all those fields?"

Uber built Schemaless — a sharding layer on top of MySQL. Interestingly, inside Uber, Schemaless was viewed ambiguously: "Schemaless was... meh. Nobody really liked using it, nobody really understood it, and you weren't really allowed to host your own instance."

Moral of the story: Uber's migration was justified by their specific problems on a specific PostgreSQL version with specific architecture (hundreds of indexes). But extrapolating this to "MySQL is better than PostgreSQL" is wrong. Instagram and Notion successfully use PostgreSQL at much larger scale.

Licensing: The Hidden Issue

Tech folks often ignore licensing. But for business, it can be critical.

PostgreSQL uses an MIT/BSD-like license. You can do whatever you want with it: modify, embed in commercial products, distribute in closed-source software. No restrictions. This is precisely why many commercial products choose PostgreSQL as an embedded database.

MySQL is under GPL-2. This is a copyleft license. If you distribute software with MySQL, you're obligated to make source code available under GPL or a GPL-compatible license. For SaaS this isn't a problem — you're not distributing software, you're providing a service. But if you're making a desktop application or embedded system, GPL creates problems.

Oracle offers a commercial license for money that removes GPL restrictions. But many proprietary software developers simply choose PostgreSQL to avoid these complications.

There's also a psychological factor. MySQL is owned by Oracle. For some companies, that's a red flag. Oracle is a large commercial corporation with a reputation for aggressive licensing. This is precisely why MariaDB appeared — a MySQL fork without Oracle. PostgreSQL belongs to the community through the PostgreSQL Global Development Group, which is more attractive to many.

Advanced Features: Where PostgreSQL Pulls Ahead

PostgreSQL earned its reputation as a "more advanced" database for good reason. The feature set is genuinely broader.

Data Types and Extensibility

PostgreSQL supports masses of non-standard data types out of the box: JSON/JSONB (with indexes!), arrays, hstore (key-value in a column), XML, UUID, geometric types, network addresses (inet, cidr, macaddr), full-text search, ranges (daterange, int4range). But the key thing — you can create custom data types.

A fintech application can create a "currency" type with validation rules and operators. A gamedev studio can create a type for game coordinates. This is a powerful capability that doesn't exist in MySQL.

MySQL is limited to standard types. There's JSON, but without indexing and with limited operators. No arrays, no custom types, no full-fledged full-text search (there's basic, but not comparable to PostgreSQL).

PostGIS and Geospatial Data

If your application works with maps, locations, geospatial queries — the choice is obvious. PostGIS for PostgreSQL is the industry standard. Uber, Lyft, food delivery, logistics — everyone uses PostGIS.

MySQL also supports spatial data, but functionality doesn't compare. PostGIS is de facto the geographic database in open source.

Row Level Security

PostgreSQL supports RLS out of the box. You define access policies at the row level directly in the database. For example: a user can see only their orders, a manager can see their department's orders, an admin sees everything.

In MySQL, this needs to be implemented at the application level or through views, which is harder and less reliable.

Transactional DDL

PostgreSQL allows executing DDL (ALTER TABLE, CREATE INDEX, etc.) inside a transaction. If something goes wrong — rollback. This is critical for safe schema migrations.

MySQL supports INSTANT/INPLACE/COPY algorithms for ALTER TABLE, which is good. But transactional DDL is absent. If ALTER TABLE fails midway — you have problems.

But MySQL Is Simpler

Here's where MySQL wins unconditionally: simplicity. Installation, basic setup, first project — everything is simpler and faster. PostgreSQL is more powerful, but complexity is the price of that power.

Replication in MySQL is easier to configure. Master-slave through binlog works out of the box. In PostgreSQL, you need to figure out primary_conninfo, replication slots, standby.signal files. For an experienced DBA, this isn't a problem. For a junior or small team — a barrier to entry.

The ecosystem of tools for MySQL is larger and more mature. Percona Toolkit, pt-online-schema-change, gh-ost, numerous GUI admin tools. For PostgreSQL, there are tools too (pgAdmin, pg_badger), but the selection is smaller and many solutions are younger.

Hosting providers. Open any shared hosting — there's MySQL. Want to run WordPress on cheap $5/month hosting? MySQL will be there by default. PostgreSQL needs to be sought out, often costs more, or requires a VPS.

Documentation and Stack Overflow. For MySQL, millions of answers to typical questions. For PostgreSQL too, but MySQL wins in quantity.

The Real Choice: Based on Task

Let's be honest. For the vast majority of applications, both databases work excellently. Problems don't start from choosing MySQL vs PostgreSQL, but from poorly designed schemas, missing indexes, unoptimized queries, insufficient hardware.

Choose PostgreSQL If

1. Your application builds complex analytics. Lots of JOINs, window functions, recursive queries. PostgreSQL's query optimizer genuinely handles complex query plans better.
2. You need advanced data types. JSONB with indexes, arrays, custom types, full-text search, geospatial queries through PostGIS.
3. Strict data consistency is critical. Transactional DDL, Row Level Security, stricter SQL standards compliance.
4. You're developing a proprietary product. PostgreSQL's BSD-like license doesn't create legal problems.
5. Your team already knows PostgreSQL. Expertise matters more than theoretical advantages.

Choose MySQL If

1. Read-heavy web application. Blog, news site, product catalog. MySQL with good caching handles this excellently.
2. You need simplicity. Small team, no dedicated DBA, need to launch a project quickly. MySQL is easier to set up and maintain.
3. You're already in the ecosystem. Using WordPress, Laravel, Drupal, other PHP frameworks where MySQL is a first-class citizen.
4. Limited hosting budget. Cheap shared hosting providers offer MySQL by default.
5. Your team knows MySQL. Again — expertise wins.

Use Both

Seriously. For complex systems, a hybrid approach can be optimal. Transactional data, users, orders — PostgreSQL with its strict consistency and ACID guarantees. Cache, sessions, simple references — MySQL for read speed. Logs, time series — specialized solutions like ClickHouse or TimescaleDB.

Or even simpler: use PostgreSQL as the main database but add Redis for caching. Or MySQL as the main database but add Elasticsearch for full-text search. Proper architecture uses the right tool for each task.

The Hidden Truth: Ecosystem Inertia

Here's an uncomfortable truth rarely discussed: most choices between PostgreSQL and MySQL are determined not by technical factors, but by ecosystem inertia and personal experience.

A developer knows MySQL because they learned on the LAMP stack and built dozens of WordPress sites. When it's time to choose a database for a new project, MySQL is the obvious choice. Comfortable, familiar, quick.

Another developer came into the industry through Django or Rails, where PostgreSQL is the recommended database. Heroku offers PostgreSQL out of the box. For them, PostgreSQL is the natural choice.

A company already has expertise in PostgreSQL. DBAs know it inside out, configured monitoring, debugged backups, wrote scripts for typical operations. Switching to MySQL means throwing away years of accumulated experience.

A startup chooses PostgreSQL because the founders read Hacker News and "all the cool kids" use Postgres. Or they choose MySQL because they want to quickly launch an MVP on Laravel and not worry about setup.

This isn't bad. Expertise, familiar ecosystem, quick start — these are real advantages. But let's admit: this isn't a purely technical choice.

Performance in Practice: What Really Matters

Yes, PostgreSQL can be faster in synthetic tests. Yes, MySQL can show better results for reads. But in production, the difference between well-tuned PostgreSQL and well-tuned MySQL is often imperceptible to the user.

What really affects performance:

Indexes. A missing index on a frequently used WHERE condition kills performance by 100-1000x. Doesn't matter if you have PostgreSQL or MySQL.

Data schema. Denormalization where needed, proper field types, reasonable use of JOIN vs denormalization. Poorly designed schema slows any database.

Configuration. PostgreSQL out of the box is configured conservatively. shared_buffers needs to be raised to 25% of RAM. work_mem, effective_cache_size, checkpoint parameters — everything requires tuning for your workload. MySQL too — innodb_buffer_pool_size should be 70-80% of RAM for a dedicated server.

Hardware. SSD vs HDD is a multiple-times difference. Enough RAM to cache the working data set is critical. Slow disks will kill any database.

Connection pooling. PostgreSQL creates a process for each connection, which is more expensive than threads in MySQL. For production, you need pgBouncer or similar pooler. For MySQL, pooling is also useful under high concurrency.

Optimizing these aspects will give much more than switching from MySQL to PostgreSQL or vice versa.

Modern Trends and the Future

PostgreSQL is gaining momentum. Stack Overflow Developer Survey shows PostgreSQL overtook MySQL and became the most "loved" database. DB-Engines Ranking gives PostgreSQL the title "DBMS of the Year 2023". New startups more often choose PostgreSQL.

Why? Several factors. Cloud providers (AWS RDS, Google Cloud SQL, Azure Database) equally support both databases well, removing MySQL's advantage in setup simplicity. Modern frameworks (Django, Rails, Laravel) work excellently with both databases. PostgreSQL's advanced features are becoming needed by more and more applications.

But MySQL isn't giving up. MySQL 8.0 and 9.0 added many improvements: window functions, CTEs, improved JSON support, descending indexes. Oracle is investing resources in development. The huge installed base guarantees MySQL isn't going anywhere.

MariaDB tries to be "better MySQL than MySQL", adding features and removing Oracle from the equation. Percona Server is another fork focused on performance.

Cloud-native forks are changing the game. Amazon Aurora is compatible with MySQL and PostgreSQL APIs, but internally it's a completely different architecture with separated storage and compute. CockroachDB, YugabyteDB, TiDB use PostgreSQL-compatible APIs but provide horizontal scalability.

Key Takeaways

PostgreSQL and MySQL are both excellent databases. The "which is better" debate is meaningless without the context of a specific task.

PostgreSQL is technically more advanced. More features, better query optimizer, stricter standards compliance, free license. If you need complex queries, advanced data types, strict consistency — PostgreSQL is an excellent choice.

MySQL is simpler and faster for typical web applications. Easier to set up, larger ecosystem, handles read-heavy workloads excellently. If you're making a blog, CMS, simple web application — MySQL works superbly.

For most applications, the difference is insignificant. Proper data schema, indexes, configuration matter more than database choice. Poorly written application will be slow on both PostgreSQL and MySQL.

The choice is often determined not by technology, but by ecosystem and experience. If your team knows PostgreSQL — use PostgreSQL. If they know MySQL — use MySQL. Retraining is more expensive than theoretical advantages of another database.

For new projects without legacy, PostgreSQL has a slight advantage thanks to advanced features and free license. But MySQL remains a completely legitimate choice, especially for simple web applications.

And finally: don't underestimate the power of "just works". If your application has successfully run on MySQL for five years, don't migrate to PostgreSQL just because "everyone says it's better". A working system is better than a theoretically optimal one.

Choose a database that solves your problem, that your team knows, and that fits the budget. Everything else is details.