Choosing a database is one of the most impactful decisions you make in a project.
It affects your application's performance, your monthly bill, and how often your team gets called at night.
When developers discuss databases, the conversation usually starts with product names: PostgreSQL, MongoDB, Redis.
Architects start differently. They first ask questions about the data, the team, and the budget. The product name is the last thing they decide.
Over the past years, I've built and scaled .NET systems using most of the databases on this list.
In this post, I'll break down every major database family: what each one is good at, what it really costs, and how to choose the right one for your project.
In this post, we will explore:
- What an architect is actually choosing
- Relational databases: PostgreSQL, MySQL and MariaDB
- Commercial relational: SQL Server and Oracle
- Embedded databases: SQLite
- Document databases: MongoDB and RavenDB
- Key-value and in-memory: Redis
- Wide-column databases: Cassandra
- Managed cloud databases
- Cloud-native databases: DynamoDB and Cosmos DB
- The specialized database families you should know exist
- How to evaluate a database before you commit
- Choosing a database in 2026
Let's dive in.
👉 Read original article on my newsletter: https://antondevtips.com/blog/how-architects-choose-a-database-in-2026
What an Architect Is Actually Choosing
When you choose a database, you're not just choosing a product.
You're choosing how your system behaves when something fails, who fixes it at night, and how much you pay every month.
Here are 6 questions that decide the choice before any product is named:
1. What shape is the data, and how do you read it? Rows with relationships, documents that you read as a whole, or values fetched by a known key? This question eliminates most of the list, and it's about the shape of your data, not the scale. I covered this split in Getting Started with System Design.
2. What does a wrong answer cost? A stale like count costs nothing. A stale account balance costs money and trust. This answer sets your consistency requirement, and consistency is the most expensive property to guarantee.
3. What is your p99 latency under real load? The p99 is the response time that 99% of requests stay under. The average hides problems, so measure the p99 with your real query mix — that's what your slowest users actually experience.
4. Who supports the database in production? A managed service moves patching, failover and backups to the provider. Self-hosting moves them to your team. Both options are valid; you just need to know which one you're signing up for.
5. What does it cost at twice today's traffic? Consumption-based pricing looks cheap at the start, but it grows with every request. Per-core licensing is predictable, but it gets expensive when you scale out.
6. What does it cost to leave? When you lock in to a specific database, moving to another one can mean a complete application rewrite.
Notice that only the first question is about the database itself.
The other five are about your team and your organization.
There is one more question that most teams skip: do you need more than one database engine at all?
Each engine can be better at its own job. Still, each one also adds operational work: backups and restores, a high-availability setup, upgrades, monitoring dashboards, driver maintenance, and people who understand it during an incident.
That adds up to weeks of platform work per year, per engine.
Two rules help you keep this under control.
First, nominate one system of record per fact.
Every piece of data has exactly one authoritative home, and every other copy is a projection you can throw away and rebuild.
Second, never dual-write.
If your application writes to PostgreSQL and to a search index in the same request, one of those writes will eventually fail, and the two stores will silently diverge.
Write to the main system of record first, and propagate the change asynchronously through an outbox or change data capture.
Finally, add a new engine only when it's roughly few times better for your workload, not 20% better.
Now let's go through each database family, starting with the most popular one.
Relational Databases: PostgreSQL, MySQL and MariaDB
PostgreSQL is the default choice for most systems, and it's what I recommend to most teams.
It's a relational database that also stores JSON documents, runs full-text search, and handles geospatial queries.
That range is the reason most projects never need a second engine.
MySQL and its fork MariaDB solve a narrower problem well: simple, high-throughput reads on a well-indexed schema, with the shortest learning curve of the three.
Strengths:
- One engine covers relational, document, search and geospatial workloads
- Mature query tooling —
pg_stat_statementsshows you which query is slow in seconds - It's easy to hire developers who already know it
Weaknesses:
- One write primary. Read replicas scale reads, but scaling writes means sharding or distributed SQL
- Self-managed failover needs extra tooling; it's not built in
- MySQL lags behind PostgreSQL on window functions, CTEs and richer types
Licensing: PostgreSQL uses the permissive PostgreSQL License and is free for any purpose.
MySQL is dual-licensed under GPLv2 or a commercial license, which you need if you bundle it inside closed-source software you distribute.
MariaDB Server is GPLv2, though its MaxScale proxy moved to a fully proprietary license in 2025.
Choose it when:
- You're building a line-of-business application and have no measured reason to do otherwise
- Your data has relationships and your reports aren't known in advance
- You want the safest hiring and tooling story available
👉 Read original article on my newsletter: https://antondevtips.com/blog/how-architects-choose-a-database-in-2026
Top comments (0)