Both are good defaults now
This used to be a more contentious debate. Today, both PostgreSQL and MySQL are mature, well-maintained, and capable of handling the vast majority of business application workloads without hitting a hard limitation. The decision matters less than most of the discourse around it suggests, but it's not arbitrary either.
Where PostgreSQL tends to win
PostgreSQL's stricter standards compliance, native support for complex data types (JSONB, arrays, ranges), and more sophisticated query planner make it a better fit for applications with complex queries, reporting workloads, or data models that don't map cleanly to plain relational tables. Its handling of concurrent writes under MVCC is also generally considered more robust for write-heavy, high-concurrency workloads.
Where MySQL tends to win
MySQL's simpler replication setup, wider hosting support (nearly every shared and managed hosting provider supports it natively), and slightly lower operational overhead for straightforward read-heavy applications still make it a reasonable default, particularly for content-driven sites and applications built on frameworks or CMSs that assume it (WordPress being the obvious example).
The decision that actually matters more
In practice, application performance problems trace back to indexing, query design and connection pooling far more often than to the choice between these two engines. A well-tuned MySQL database will outperform a poorly indexed PostgreSQL one, and vice versa. If you're migrating an existing application, the cost of switching engines rarely justifies the marginal gains, unless you're hitting a specific, well-understood limitation of your current one.
If you're starting fresh with no constraint pulling you either way, and your data model is relational and reasonably complex, PostgreSQL is the safer long-term default. If you're building something simple and fast, on infrastructure that already assumes MySQL, there's little reason to fight that.