In short
For a new project, Postgres is the better default: richer data types, stricter correctness by default, and stronger support for JSON, full-text search and complex queries. MySQL remains a sound choice, particularly on managed hosting where it is the standard offering or where an existing team knows it well. The decision matters far less than schema design and indexing.
The honest starting point
Both are mature, fast, and capable of running large systems. Almost no application fails because it chose one over the other.
What actually determines database performance is schema design, indexing, and query quality. A well-designed MySQL database outperforms a poorly designed Postgres one every time.
So treat this as a preference decision with a few real tie-breakers, not an architectural crossroads.
Where Postgres is genuinely ahead
Data types. Native arrays, ranges, network addresses, geometric types, and a strong JSON implementation. If your domain has a natural type, Postgres probably has it, and using it beats encoding into strings.
JSON handling. jsonb stores JSON in a binary form that can be indexed and queried efficiently. This is genuinely useful for semi-structured data alongside relational data, and it is better than MySQL's equivalent.
Correctness by default. Historically MySQL was permissive — silently truncating values or accepting invalid dates. Modern versions are much stricter, but Postgres has been strict throughout, which matters if you would rather a write fail loudly than succeed wrongly.
Complex queries. Window functions, common table expressions, recursive queries, and a planner that handles complicated joins well. If your application does real analytical work, this is the clearest difference.
Extensions. Full-text search, geospatial via PostGIS, and vector similarity for embeddings — the last increasingly relevant for anything doing retrieval over documents. Being able to add these to your existing database rather than running a separate service is a real simplification.
Concurrent index creation without locking writes, which matters for safe migrations on large tables.
Where MySQL still holds up
Availability on cheap hosting. On shared and low-cost managed hosting, MySQL or MariaDB is frequently what you get. That is a genuine constraint, and fighting it is rarely worth it.
Simple read-heavy workloads. For straightforward queries at high volume, performance is comparable and the operational footprint is slightly simpler.
Replication familiarity. MySQL replication is long-established and widely understood, and plenty of operations teams know it well.
Existing expertise. A team that knows MySQL will build something better in MySQL than something mediocre in Postgres while learning. This is the most legitimate reason to choose it and is often undervalued.
Ecosystem defaults. Some platforms and CMSes assume MySQL. Swimming against that costs more than the difference is worth.
Differences that no longer decide anything
Several long-standing arguments have expired.
MySQL's default engine has supported transactions and foreign keys for many years. Both handle JSON, both do replication, both scale well beyond what most applications need. Older comparisons still circulating are frequently describing versions from a decade ago.
What should actually decide it
What your hosting offers. If your platform provides one as a managed service with backups and failover, take it. Managed beats self-hosted for almost every team, and the operational difference dwarfs the feature difference.
What your team knows. Real expertise is worth more than a feature list.
Whether you need the specific strengths. Geospatial, vector search, complex analytical queries, or unusual data types point clearly at Postgres.
What your framework assumes. Both are supported everywhere, but defaults and documentation lean one way in some ecosystems.
The recommendation
For a new project with a free choice: Postgres. Richer types, stricter defaults, better JSON, and the extension ecosystem means fewer separate services later. Managed Postgres is widely available and inexpensive.
Choose MySQL when your hosting provides it, your team knows it well, or your platform assumes it. Those are good reasons and the outcome will be fine.
Do not migrate an existing working system on the strength of a feature comparison. Migration is expensive, risky, and rarely pays back unless you need something specific — vector search or PostGIS being the usual legitimate cases.
And whichever you pick, spend the time you would have spent debating on the schema and the indexes. That is where the performance actually is.
If you are choosing a stack for something long-lived, book a call.
Common questions
Should I use Postgres or MySQL for a new project?
Postgres, if you have a free choice — richer data types, stricter correctness by default, better JSON support through jsonb, and extensions for full-text search, geospatial and vector similarity. MySQL remains a sound choice where your hosting provides it or your team already knows it well.
Is Postgres faster than MySQL?
Not meaningfully, in the general case. Both are fast, and real database performance is determined by schema design, indexing and query quality — a well-designed MySQL database outperforms a badly designed Postgres one every time. Postgres pulls ahead specifically on complex analytical queries.
What can Postgres do that MySQL cannot?
Native arrays, ranges and other rich types; indexable binary JSON; stronger window functions and recursive queries; concurrent index creation without locking writes; and extensions including PostGIS for geospatial and vector similarity for embeddings, which avoids running a separate service.
Should I migrate from MySQL to Postgres?
Not on the strength of a feature comparison alone. Migration is expensive and risky, and rarely pays back unless you need something specific — vector search and PostGIS are the usual legitimate reasons. A working system is worth more than a marginally better one.
Are the old arguments about MySQL still valid?
Mostly not. Its default engine has supported transactions and foreign keys for many years, modern versions are far stricter about invalid data, and both databases handle JSON and replication well. Many comparisons still circulating describe versions from a decade ago.
