PostgreSQL or MySQL: which database to choose for a new project

For a new web project our default is PostgreSQL: it is stricter with data, richer in features — JSON, full-text search, extensions such as PostGIS and pgvector — and lets you go longer without extra data stores. MySQL remains a good choice when your team knows it deeply, your hosting only supports it, or the project is a classic CMS-based site.

Let us look at where the two databases really differ and where the gap closed long ago.

How do PostgreSQL and MySQL differ in 2026?

PostgreSQL and MySQL differ mainly in philosophy: PostgreSQL evolves as an extensible object-relational database focused on correctness and SQL standards, MySQL as a fast, easy-to-run database for web applications. Both have closed most gaps in recent years, so the difference now lies in the extension ecosystem and behaviour on complex queries.

Arguments that used to matter and no longer do:

• "MySQL is faster on simple queries" — for a typical web app the difference is negligible; indexes and schema design are the bottleneck;
• "MySQL has no window functions or CTEs" — it has had them since version 8.0;
• "PostgreSQL is hard to operate" — managed cloud services exist for both.

Which features does only PostgreSQL have?

PostgreSQL has features that MySQL either lacks or implements noticeably less well: rich data types, partial indexes, powerful JSONB and an extension system. For a product, this means many tasks can be solved inside one database without a separate search engine or geo service.

Feature	PostgreSQL	MySQL
Indexed JSON documents	JSONB with GIN indexes	JSON type, indexes via generated columns
Partial indexes	Yes	No
Full-text search	Built in, with stemming and ranking	Built in, more limited
Geospatial data	PostGIS extension, the industry standard	Basic spatial types
Vector search for AI	pgvector extension	No standard community solution
Transactional schema changes	Yes, a migration can roll back entirely	Most DDL cannot be rolled back
Arrays, ranges, enums	Native types	Limited

Here is a partial index that often comes in handy: a unique email only among users who have not been deleted.

CREATE UNIQUE INDEX users_email_active_unique
    ON users (lower(email))
    WHERE deleted_at IS NULL;

In MySQL the same task needs a workaround — a generated column or a check in application code.

Photo: Unsplash

When is MySQL a sensible choice?

MySQL is a sensible choice when a MySQL ecosystem already surrounds the project: the team knows how to operate it, the application is built on a CMS that works best with MySQL, or the hosting offers nothing else. Moving a healthy MySQL setup to PostgreSQL without a concrete reason is not worth it either.

Situations where we keep or choose MySQL:

• a WordPress site or another CMS designed around MySQL;
• an existing project where MySQL runs reliably and does not hold development back;
• the client's team has run MySQL for years and will maintain the database themselves;
• the workload is mostly simple primary-key reads and advanced features are not needed.

How does the database choice affect framework and hosting?

The database barely affects your framework choice: Laravel, Django, Rails, NestJS and others support both through their ORMs. But an ORM only smooths over basic operations — once the project uses JSONB, partial indexes or full-text search, the code is tied to a specific database.

What to check when choosing hosting

Every major cloud provider offers managed versions of both databases, with automatic backups, replicas and updates. Check in advance:

1. Which database versions are available and how quickly new ones arrive.
2. Which PostgreSQL extensions are allowed — pgvector and PostGIS are not available everywhere.
3. How backups and point-in-time recovery work.
4. What a read replica costs if you need one.

Can you switch databases later?

You can switch later, but it is a separate project involving data migration, query review and testing — not a connection string change. The more a project relies on database-specific features, the more expensive the move.

How a MySQL-to-PostgreSQL migration usually goes:

1. Inventory: which queries, types and functions are MySQL-specific.
2. Schema migration with type adaptation — for example, TINYINT(1) to boolean, DATETIME to timestamptz.
3. Data transfer with a tool such as pgloader, then checking row counts and checksums.
4. Running tests and comparing the results of key queries on both databases.
5. Cutover during a maintenance window or via replication, with a rollback plan.

That is why the initial choice matters: it determines which capabilities the product gets without extra infrastructure.

In short

• For a new product default to PostgreSQL: strictness, JSONB, search, PostGIS and pgvector in one database.
• MySQL makes sense for CMS projects, existing systems and teams with strong MySQL expertise.
• Speed on typical web workloads is not an argument: indexes and schema decide.
• An ORM hides the differences only until the first database-specific query.
• Switching later is possible, but it is a separate project with migration and testing.