Why Companies Don't Store Everything in One Database
Replication, sharding and read replicas — why large systems split data across many databases, and the trade-offs each strategy forces you to accept.
- System Design Fundamentals
- Databases
- Backend
- System Design
- Software Architecture
When I first started building applications, I assumed the database was simple.
- Pick one.
- Store data.
- Move on.
The more systems I worked on, the more I realized that databases are really a series of trade-offs. Take an e-commerce platform.
- Product catalog data.
- User profiles.
- Orders.
- Analytics.
- Search.
Should all of that live in the same database? It can. But that doesn't mean it should.
- Search systems are optimized for search.
- Analytics systems are optimized for large-scale reporting.
- Transactional databases are optimized for consistency.
Trying to make one database solve every problem usually creates a different problem.
One thing that changed how I think about System Design: There is no "best" database.
There is only the best database for a specific workload. That's why modern architectures often combine multiple storage systems. Not because engineers like complexity. Because different problems have different requirements.
The real question isn't:• Which database should we use? It's:
- What are we optimizing for?
- Performance?
- Consistency?
- Scalability?
- Search?
- Analytics?
The answer usually shapes the architecture more than the technology itself.
Question: What's the most interesting database decision you've seen in a real system?
Keep reading
Every Large-Scale System Is Sacrificing Something
The CAP theorem without the jargon. Every distributed system trades consistency, availability or partition tolerance — the skill is choosing deliberately.
The Fastest Database Query Is the One You Never Execute
Caching explained from first principles — what to cache, where to put it, and why the cheapest query is the one your database never sees.
One Server Is Never the Problem. One Server Is the Risk
A single server is not a performance problem, it is an availability problem. How load balancing removes the single point of failure before it costs you uptime.