Why Choosing the Right Database Matters

The Most Famous Product Is Not the Answer

Part 5 of 12 in "Databases for Non-Developers". This installment explains why choosing a database is a business decision, not a matter of technical taste — and what questions to ask before ever uttering a product name.

Deep dive: For concrete product comparisons and a breakdown of cost structures, see the Guide to Choosing a Modern Cloud Database.

---

When starting a new service, it's easy to ask, "Which database is the fastest?" But this question alone rarely leads to the right answer. It's like asking whether a sedan or a truck is better. Without knowing your destination and your cargo, the question has no answer.

Choosing a database is not just a matter of technical taste. It affects service speed, the risk of outages, development time, operations staff, security, cost — and how hard it will be to change products later. And it's the business as a whole, not just the development team, that bears the consequences.

What Happens When You Choose Wrong?

1. Important Information Starts to Disagree

If you force a weak-consistency approach onto work that requires accurate transactions, inventory counts, balances, and reservation statuses can start to look different on every screen. This is the result of choosing poorly, and the accuracy mechanisms we saw in Part 2 are only as strong as that choice.

2. Speed Plummets as Users Grow

At first, every product can look fast. But as data volume, concurrent users, and query patterns grow, the differences reveal themselves. If the structure doesn't match the questions you ask most often, adding more servers may only grow your bill. Slow page loads are not a technical metric — they're a churn and revenue problem.

3. Even Small Changes Become Hard and Expensive

If product attributes keep changing but the structure is too rigid, every change may require a major rework. On the flip side, if a place that needs clear standards — like accounting records — is given too loose a structure, the data becomes hard to keep clean. Both rigid and lax structures come at a price.

4. There's No One to Run It

Even a feature-rich product is a bad choice if your team can't handle installation, monitoring, backups, and disaster recovery. You should also look at the size of the hiring market, external support options, documentation, and the quality of managed services. Remember: the newer the technology, the rarer the experts, and the harder outage response and hiring become.

5. Unexpected Costs Creep In

Don't price a database by storage space alone. Read and write requests, data transfer, backups, replicas, logs, technical support, and operations staff all cost money. It's especially easy to overlook the egress fees charged when data leaves the cloud. Compare not the "purchase price" but the total cost of ownership (TCO) over 3–5 years.

6. Migration Becomes Painful Later

If you lean heavily on features only one product offers, the cost of switching grows. This is called vendor lock-in. Replacing a database is famously compared to "swapping an airplane's engine mid-flight." Lock-in isn't inherently bad — it can be a reasonable trade if a vendor's unique features let you deliver value faster. But you must understand that choice and its exit cost before you commit.

Ten Questions to Ask Before Any Product Name

1. What are we storing? Customers, payments, documents, sensor readings, images — which is it?
2. What questions will we ask most often? Looking up a single customer, or analyzing years of records?
3. How critical is accuracy? Can we tolerate a difference of a few seconds?
4. How fast does it need to be? How long will users wait?
5. How much is coming in? Look at the daily total, but also at peak moments when traffic surges.
6. Does the data structure change often? How frequently do new fields and relationships appear?
7. How long can the service be down? By when must it be recovered after a failure?
8. How much data loss is acceptable? None at all, or can we live with losing the last few minutes?
9. Who will run it? How experienced is the team, and can they respond around the clock?
10. What legal and contractual requirements apply? Are there rules on storage region, retention periods, encryption, or audit logs?

Question 7 is called the recovery time objective (RTO), and question 8 the recovery point objective (RPO). An RTO of 2 hours means the goal is to restore service within 2 hours of a failure. An RPO of 15 minutes means the design accepts losing up to the last 15 minutes of data in the worst case. These numbers must be set by the business, not the tech team — "how many hours of downtime will our customers tolerate?" is a business question.

Realistic Principles for Small Teams

Newer technology is not always the better choice. For much everyday work, a widely used relational database combined with a managed service is plenty. You can always add search, caching, or vector stores later, once your service's special needs become clear.

Every additional database adds another target for backups, permissions, monitoring, version upgrades, and outage response. More technology does not equal more capability.

Test with Real Workloads, Not Brochures

Rather than comparing performance numbers from product brochures, it's better to reproduce, on a small scale, the tasks your service will actually perform. Test with realistic data volumes, concurrent users, your most complex queries, and your failure-recovery procedures. The purpose of a proof of concept (PoC) is not a dazzling demo — it's to validate your most important assumptions. Assumptions like "will it hold up if users grow tenfold?" or "can one person run this operationally?"

Key takeaways The right database is not the fastest or the newest product — it's the one that fits your workload's accuracy, speed, scale, operational capacity, cost, and regulatory requirements. Before choosing, define what you'll store and the questions you'll ask most often. For small teams, it's safest to start simple and add new storage only when a clear problem demands it.

Questions to Ask at the Decision Meeting

• What is the most important problem this choice solves?
• Why can't our current database solve the same problem?
• Does the three-year total cost include staffing, backups, data transfer, and support?
• If an outage strikes, who restores service, in what order?
• When we need to leave this product, how will we move our data and functionality?

Next up: a look at the data modeling and data quality problems no database choice can save you from. What happens when you store bad goods in a good warehouse — the story of "Garbage In, Garbage Out."

---

Series contents

1. What Is a Database — and How Is It Different from an Excel File?
2. How Databases Protect Accuracy
3. What Kinds of Databases Are There?
4. Databases, Data Warehouses, and Data Lakes
5. Why Choosing the Right Database Matters ← You are here
6. Data Models and Data Quality
7. What Is Data Governance?
8. Collect Less Personal Data — Only What You Need
9. The Basics of Data Security
10. Why Data Breaches Happen, and What to Do When One Does
11. Cloud and Serverless Databases
12. Databases in the AI Era