The PostgreSQL versus MySQL debate has raged for decades. Passionate advocates on both sides will tell you their choice is obviously superior. The truth is more nuanced: both are excellent relational databases suitable for most applications, but they have genuine differences that matter for specific use cases.

I’ve run both in production across different projects. I have opinions, but I’ll try to be fair about where each excels and where each has limitations.

Performance: It Depends

Benchmarks are mostly useless for real-world decision making because performance depends entirely on workload characteristics, configuration, and infrastructure.

MySQL historically had a reputation for being faster on simple read queries, particularly with the InnoDB storage engine. PostgreSQL was considered more robust for complex queries but slower on basic operations. That gap has narrowed significantly. Modern Postgres performs excellently on simple queries, and MySQL’s optimizer has improved for complex queries.

Write performance depends heavily on your specific use case. PostgreSQL’s MVCC (Multi-Version Concurrency Control) implementation handles concurrent writes differently than MySQL. For high-concurrency workloads with many small writes, the differences can be significant, but there’s no clear universal winner.

Both databases can handle thousands of queries per second on appropriate hardware with proper tuning. If you’re choosing based on raw performance, you’re probably optimising prematurely unless you have very specific performance requirements backed by benchmarks using your actual workload.

Feature Set: Postgres Wins

This is where the differences become clearer. PostgreSQL supports a much richer feature set for advanced use cases.

Postgres has proper support for JSON and JSONB data types with efficient querying. You can store semi-structured data alongside relational data and query it efficiently. MySQL added JSON support later and it’s less mature.

Full-text search in Postgres is built-in and powerful. MySQL has full-text search but it’s more limited. If your application needs text search capabilities, Postgres gives you more options before requiring external search engines like Elasticsearch.

Common Table Expressions (CTEs), window functions, and advanced SQL features are all first-class in PostgreSQL. MySQL added these features over time, but PostgreSQL’s implementation is often more complete and better documented.

Custom data types, extensions like PostGIS for geographic data, and the ability to write stored procedures in multiple languages (PL/pgSQL, Python, Perl) make Postgres extremely flexible for complex applications.

If you need these advanced features, Postgres is the clear choice. If you’re building a straightforward web application with standard CRUD operations, you won’t benefit much from these capabilities.

Standards Compliance

PostgreSQL is obsessively standards-compliant with the SQL specification. MySQL takes a more pragmatic approach, implementing what’s useful and skipping or modifying standards where the creators felt it made sense.

This matters if you’re writing portable SQL that needs to work across databases, or if you’ve got team members trained on standard SQL who expect it to work a certain way.

MySQL historically defaulted to more permissive behaviour around things like invalid dates or truncated data. You could insert “0000-00-00” as a date and MySQL would accept it. Postgres is stricter and would reject invalid data.

Modern MySQL can be configured to be more strict, but the defaults matter because they shape how developers use the database. Postgres encourages correct data modelling through strictness. MySQL’s permissiveness can be convenient or dangerous depending on perspective.

Replication and High Availability

Both databases support various replication topologies. PostgreSQL’s streaming replication is solid and well-understood. MySQL’s replication has been around longer and has more operational experience behind it in high-scale deployments.

MySQL’s Group Replication and InnoDB Cluster provide multi-primary setups where you can write to multiple nodes. PostgreSQL typically uses single-primary replication with hot standbys for read scaling and failover.

For high availability, both have mature solutions. Patroni and repmgr for Postgres, Orchestrator and ProxySQL for MySQL. Cloud-managed services from AWS, GCP, and Azure handle this complexity for you with either database.

I haven’t found meaningful differences in HA capabilities. Both can achieve highly available architectures with appropriate tooling and operational expertise.

Operational Considerations

PostgreSQL’s upgrade path can be painful. Major version upgrades sometimes require dump/restore or pg_upgrade tools that create downtime and stress. MySQL’s upgrades are generally smoother with better backward compatibility.

That said, Postgres’s versioning is predictable. A new major version annually, with clear deprecation policies. MySQL’s ownership changes (Sun, then Oracle) created uncertainty at times, though the MariaDB fork addressed some concerns.

Configuration tuning differs significantly. PostgreSQL has many parameters that significantly affect performance, and defaults are often conservative. You need to tune shared_buffers, work_mem, effective_cache_size, and others based on your workload and hardware.

MySQL’s defaults are generally more sensible for common use cases. InnoDB’s buffer pool and other key settings still need tuning for production, but the default experience is smoother for beginners.

Ecosystem and Tooling

MySQL has been around longer and has wider adoption, particularly in the PHP/WordPress/Drupal ecosystem. More hosting providers support MySQL by default. More third-party tools integrate with MySQL first.

PostgreSQL’s ecosystem has grown massively. Modern frameworks and ORMs support both databases equally. Cloud platforms treat them as equals. The tooling gap has largely closed.

For monitoring, logging, and management, both have mature options. pgAdmin for Postgres, MySQL Workbench for MySQL. Prometheus exporters exist for both. Commercial monitoring tools support both.

Licensing and Governance

PostgreSQL uses a permissive PostgreSQL License (similar to MIT/BSD). It’s truly open source with no corporate owner. Development is community-driven through a transparent process.

MySQL is owned by Oracle, which makes some people uncomfortable. MySQL uses GPL licensing, which has implications for commercial products embedding it. MariaDB exists as a community fork for those concerned about Oracle’s stewardship.

For most users, licensing differences don’t matter. But if you’re building a commercial product or have strong open-source preferences, these differences might influence your decision.

What I Actually Choose

For new projects where I’m starting from scratch and expecting complex queries, rich data types, or advanced SQL features, I default to PostgreSQL. The feature set gives me more flexibility, and I prefer the development experience.

For projects with specific ecosystem requirements (like WordPress or certain legacy applications), MySQL is the pragmatic choice because the ecosystem is built around it.

For simple applications where database choice genuinely doesn’t matter, I pick whatever I’m most familiar with or what the team already knows. The difference in productivity from using a familiar database outweighs any theoretical technical advantages.

The Honest Answer

Both databases are mature, performant, and reliable. You won’t make a career-ending mistake choosing either one for most applications.

PostgreSQL offers more advanced features, stricter standards compliance, and a truly open governance model. It’s the better choice if you value these things or need the advanced capabilities.

MySQL offers wider hosting support, smoother upgrades, and a massive existing ecosystem. It’s the better choice if these factors matter more for your project.

Performance differences exist but they’re workload-specific. Configuration and indexing strategy matter far more than the database choice for most performance concerns.

Read the PostgreSQL documentation and MySQL documentation for your specific use case. Understand how each handles your requirements. Make a decision based on your actual needs rather than internet debates.

I’ve built successful applications on both. The database choice mattered less than proper schema design, appropriate indexing, and understanding the specific database’s characteristics. Pick one, learn it deeply, and you’ll be fine.