Choosing a Database in 2026: PostgreSQL, MySQL or MongoDB?

Most "which database" articles end without an answer, having listed the strengths of each. That is not helpful when you have to pick one this week.

So, the answer first: for a new project in 2026, use PostgreSQL unless you have a specific reason not to. The rest of this explains why, and — more usefully — the cases where that is wrong.

Why PostgreSQL is the default

Not because it wins every benchmark. Because it has the fewest situations where you regret it.

It does the other databases' jobs adequately. Postgres has had proper JSON support for years — jsonb with indexing — so "we need flexible documents" no longer requires a document database. It has full-text search, so a small application does not need a separate search engine. It has geospatial support through PostGIS, and increasingly vector search through pgvector, which matters if you are building anything with embeddings.

Each of those is worse than the specialist tool. Each is good enough that a small or medium application does not need a second database — and one database you understand well beats three you understand adequately.

Correctness by default. Strict typing, real constraints, transactional DDL — you can roll back a migration. Postgres tends to refuse to store something wrong rather than accepting it and surprising you later.

It is boring. Two decades of production use, excellent documentation, an unremarkable licence, and available from every host and every managed provider. Nobody is going to change its terms.

When MySQL is the right answer

Genuinely, sometimes.

You are running WordPress, or almost any PHP application. WordPress requires MySQL or MariaDB. This is not a preference. Do not fight it — see speeding up WordPress for what actually helps there.

You are on shared hosting. Most shared plans offer MySQL and nothing else. If that is your deployment target, the decision is made for you. if you would rather not test that yourself, our shared hosting sets CloudLinux limits per account and runs on NVMe.

Your team already knows it well. A team fluent in MySQL will ship better software on MySQL than on a Postgres they are learning. Familiarity is a real engineering property.

MySQL in 2026 is a good database. The gap that existed a decade ago has mostly closed. It is simply that Postgres has closed it from the other side and kept going.

When MongoDB is the right answer

Narrower than its marketing suggests, and real.

Genuinely schemaless data. Documents whose shape varies per record and cannot be usefully normalised — arbitrary event payloads, per-tenant custom fields, content from many sources with different structures.

Write-heavy, denormalised workloads where you read whole documents and rarely join.

Your team thinks in documents, and the application is not relational underneath.

Where it goes wrong: using it because "schemas are annoying". Your data has a schema regardless — the only question is whether it is enforced by the database or implied by your application code and violated in production. Teams who choose Mongo to avoid migrations tend to end up performing migrations anyway, in application code, without transactions.

The specific failure to watch for: needing joins. If you find yourself doing multi-collection lookups routinely, you have a relational model in a document database, and it will get harder every quarter.

SQLite deserves more consideration than it gets

Most developers dismiss SQLite as a toy. In 2026 that is out of date.

It is a serious database, and for a large class of applications it is the best choice:

• A single-server application with moderate write volume. No network hop, no connection pool, no second process to run and patch.
• Read-heavy workloads. With WAL mode, readers do not block and performance is excellent.
• Edge deployments, where a network round trip to a database defeats the purpose.
• Every test suite you will ever write.

Its real limits: one writer at a time, and it lives on one machine's disk. If you need many concurrent writers or horizontal scaling, it is the wrong tool. Otherwise the operational simplicity is worth a great deal — the database you never have to administer is the one that never wakes you up.

The comparison that matters

The mistakes that actually hurt

Choosing wrongly between these four is recoverable. These are not.

1. No indexes on your foreign keys and filter columns. The single most common cause of "our database is slow". A query with no index does a full scan, and it is fast at a thousand rows and catastrophic at a million. It will pass all your tests.

-- PostgreSQL: which queries are actually slow?
SELECT query, calls, mean_exec_time
FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;

2. N+1 queries. Your ORM fetches 50 rows, then issues 50 more queries — one per row — to load a relation. It looks like clean code, and it is 51 round trips. Almost every ORM has an eager-loading option; almost nobody uses it until the page takes four seconds.

3. Storing money in a float. 0.1 + 0.2 is not 0.3, and the errors accumulate silently until an accountant finds them. Use numeric/decimal, or store integer paisa.

4. No connection pooling. Each connection costs memory. An application opening one per request will exhaust the server under load — and it works perfectly in development, where there is one user.

5. Backups nobody has restored. Same argument as server hardening: an untested backup is a belief. Restore one to a scratch server every quarter.

6. Storing timestamps without a timezone. Use timestamptz. This is a two-character decision that determines whether your data is unambiguous in three years.

Scaling, and when to worry

Almost nobody needs to think about horizontal scaling, and a great deal of engineering time is spent preparing for a scale that never arrives.

The realistic order of operations:

1. Add the missing index. This solves most "we need to scale" moments outright.
2. Fix the N+1 queries.
3. Add caching in front of expensive reads.
4. Get a bigger machine. Vertical scaling is unfashionable and remarkably effective — a modern server handles far more than people assume, and it costs less than an engineer-month of re-architecture. This is often the point where a dedicated server starts to pay for itself.
5. Add read replicas if reads dominate.
6. Then, and only then, consider sharding or a distributed database.

Most applications never get past step four. Designing for step six from the start is the most reliable way to spend a year building something you do not need.

How to actually decide

1. Is your platform forcing it? WordPress means MySQL. Shared hosting usually means MySQL. Decision made.
2. Is your data genuinely non-relational — variable shape, no joins? Consider MongoDB. Be honest here; most data that feels non-relational is relational data nobody has modelled yet.
3. Single server, moderate writes, want minimal operations? SQLite is a serious answer.
4. Anything else? PostgreSQL.

Then stop thinking about it. The database choice matters far less than the schema you design and the indexes you add, and those are where the time is better spent. If the modelling is the part you would rather hand over, if the system is bigger than a weekend, we take this on as a fixed-scope project.

Managed or self-hosted?

A separate decision from which database, and often the more consequential one.

A managed database — from your cloud provider or a specialist — handles backups, patching, failover and monitoring. You pay a premium, sometimes a large one, and in exchange nobody on your team needs to know how to restore a corrupted cluster at 3am.

Self-hosting on your own server is much cheaper in money and considerably more expensive in attention. You own the backups, the version upgrades, the replication if you need it, and the incident response.

The way to decide is not cost per month. It is this: is there somebody on your team who would know what to do if the database would not start? If the honest answer is no, buy managed. The premium is smaller than one bad outage.

Two things people get wrong in both directions:

Self-hosting without backups you have restored. Running Postgres on a VPS is genuinely fine — right up to the point where the disk fills, or a migration goes wrong, and the last verified restore was never. If you self-host, restore to a scratch server quarterly. It takes an hour and it converts a belief into a fact.

Buying managed and assuming it is backed up the way you think. Check the retention period, check whether point-in-time recovery is included on your tier, and check whether your provider's backups are in the same region as your database. Managed means somebody is doing it; it does not mean they are doing what you assumed.

Either way, keep an independent copy somewhere your cloud account cannot delete. That protects against the failure neither option covers: losing access to the account itself.

Frequently asked questions

Is PostgreSQL better than MySQL in 2026? For a new project without platform constraints, generally yes — richer types, better JSON, transactional DDL, stronger extensions. But MySQL is a good database, and if your platform requires it or your team knows it well, that is the stronger consideration.

When should I use MongoDB instead of a relational database? When your documents genuinely vary in shape and you rarely need joins. If you find yourself routinely looking up across collections, you have relational data in a document store and it will get harder, not easier.

Can PostgreSQL replace MongoDB? For many use cases, yes. jsonb with GIN indexing handles document-style data well. It is not as good as Mongo at that specific job, but it is good enough that most applications do not need a second database.

Is SQLite production-ready? Yes, for single-server applications with moderate write concurrency. It powers a great deal of production software. Its limits are one writer at a time and no horizontal scaling — everything else about it is an operational advantage.

What database should I use with WordPress? MySQL or MariaDB. WordPress requires it, and this is not a choice worth fighting. Spend the effort on caching and query optimisation instead.

How do I know if my database is the bottleneck? Look at slow query logs and per-query timings before assuming. The usual culprits are a missing index or an N+1 query pattern, and both are far cheaper to fix than any hardware or architecture change.