PostgreSQL or MySQL?

If you’ve already settled on a relational database, one common fork remains: PostgreSQL or MySQL? Both are mature, open, and free to run, and both power large parts of the web. But recent years’ developments have clearly shifted the balance. Here’s where things stand in 2026 and how to choose.

Postgres’s feature breadth – why it became the default

What has made PostgreSQL the first choice for new projects is its breadth. It’s not just a relational database – it’s a relational database that handles much of what used to require separate tools.

• Real JSON. Postgres can store and search JSON documents almost as smoothly as a document database, while you keep tables and relations for everything else. You often avoid having to choose between structure and flexibility.
• Built-in full-text search. Simpler search needs can be handled directly in the database, without a separate search engine. That keeps the architecture simpler in early stages.
• Extensions. Postgres can be extended with add-on modules. The most talked-about one lately is pgvector, which lets the database store and search vectors – the foundation for AI features like semantic search. That means AI-adjacent products can keep their vector data in the same database as everything else.

The sum of it is a database that grows with the project. When needs become more advanced, the solution is often already built in, instead of requiring a new component in the architecture.

MySQL’s remaining strongholds

MySQL isn’t in retreat – it’s still one of the most widely used databases in the world. Its strength lies in maturity, simplicity, and reach.

The classic web stack is built around MySQL, and a large share of everything that powers the web runs on it. For clean, well-defined web applications, it’s fast, well proven, and easy to get started with. And where MySQL is already in place and working, it’s rarely worth switching – a working database is a poor place to look for savings.

In short: MySQL wins on inertia, in the best sense of the word. What’s already there, already staffable, and already doing its job.

A scenario: the same app, two outcomes

Say you’re building a service that starts as a simple web application but where you suspect AI-driven search might come later. Choose MySQL now and everything works great – until the search need shows up, and you have to add a separate vector database and keep two systems in sync. Choose Postgres from the start and that possibility sits latent in the database you already have; the day the need arrives, you activate an extension instead of extending the architecture. Neither path is wrong, but one has fewer moving parts as the ambition grows.

Migration and hiring in Sweden

Two practical questions often decide the choice as much as the features do: how hard is it to switch, and are there people who know the technology?

Migrating from MySQL to Postgres can be done, but it’s not free. The basics are similar, but data types and certain queries differ and have to be rewritten. For a small database, it’s manageable; for a large one, it’s a project of its own. Do it because you need Postgres’s features, not to follow the trend.

On the expertise side, the situation in Sweden is comfortable. Postgres’s popularity means more and more developers know it well, and MySQL knowledge has been plentiful for a long time. Staffing therefore rarely decides the choice – both can be hired for.

How to choose

Starting something new without strong reasons pointing elsewhere: choose PostgreSQL. Its breadth and built-in features make it the safest default, especially if AI or advanced search might become relevant. Already sitting on MySQL and it’s working: don’t switch without a concrete reason.

If you’d like help choosing a database or reading where your product is headed, we at Weapp are glad to look at it as part of the systems work. Get in touch so we can talk through the choice before it settles into the code.