Choosing the Right Database
There is no "best" database. There is only the best fit for your requirements. This lesson gives you a decision framework: systematic questions that lead to the right choice for your specific workload.
Decision Axes
Five Dimensions to Evaluate
- Data model — Is your data structured (tables), semi-structured (documents), key-value, graph, or time-series?
- Access patterns — How will you read and write? By key? Complex queries? Range scans? Graph traversals?
- Consistency needs — Can you tolerate eventual consistency, or do you need strict ACID?
- Scale requirements — How much data? How many reads/writes per second? Will it grow 10x?
- Operational complexity — What can your team operate? Do you have DBA expertise? Prefer managed services?
Decision Tree
Polyglot Persistence
Modern systems rarely use a single database. Instead, they use multiple databases, each handling what it's best at:
Airbnb's Data Architecture
- MySQL — Core transactional data: bookings, payments, user accounts. Needs ACID guarantees.
- Elasticsearch — Search: "Find apartments in Paris, 2 bedrooms, under $150/night, with WiFi." Full-text + faceted search.
- Redis — Caching: session data, rate limiting, real-time availability. Sub-millisecond reads.
- Hive/Spark — Analytics: "What's our average booking value by city by month?" Scan billions of rows.
- Kafka — Event streaming: connecting all these systems, ensuring data flows between them.
Each database handles a specific workload. The complexity is in keeping them synchronized — which is why event-driven architectures matter.
When to Use What
| Workload | Best Choice | Why |
|---|---|---|
| E-commerce orders | PostgreSQL / MySQL | ACID for money + inventory |
| User sessions | Redis | Fast by-key access, TTL expiry |
| Product search | Elasticsearch | Full-text, facets, fuzzy matching |
| Social feed | Cassandra / DynamoDB | Write-heavy, partition by user |
| Recommendations | Neo4j | Traverse relationships efficiently |
| IoT sensor data | TimescaleDB / InfluxDB | Time-series optimized writes + queries |
| Business reports | ClickHouse / BigQuery | Columnar scan over billions of rows |
| CMS content | MongoDB | Flexible schema, nested documents |
Migration Strategies
Sometimes you realize you picked the wrong database (or outgrew it). Migrating without downtime requires careful orchestration:
The Dual-Write Migration Pattern
- Set up new database alongside the old one
- Dual-write — Write to both old and new DB on every operation
- Backfill — Copy all historical data from old to new
- Verify — Read from both, compare results (shadow reads)
- Switch reads — Point read traffic to new DB
- Remove old writes — Stop writing to old DB
- Decommission — Remove old database
Critical: Steps 2-4 can take weeks. You need tooling to detect inconsistencies between the two databases.
Interactive: Database Selection Wizard
Answer questions about your system and get a database recommendation.