Database Types
Choosing the right database for each component of your system is a core design skill.
Quick answer: Database Types
Database Types is covered here as a practical system design concept. Choosing the right database for each component of your system is a core design skill. Use it to understand the Databases idea, where it appears in production systems, and how to discuss it clearly in interviews.
Focus on the problem being solved, the main design choice, the failure mode, and the tradeoff you would defend in front of a senior engineer. This page is part of the DosiBridge system design knowledge graph, so it links related concepts, interview problems, tradeoffs, and references instead of leaving the topic isolated.
When You Need Database Types
Choosing the right database for each component of your system is a core design skill. In interviews, you should be able to explain why you chose PostgreSQL for user data, Redis for caching, and Elasticsearch for search.
What It Is
There are many types of databases, each optimized for specific use cases: relational (PostgreSQL, MySQL), document (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra, HBase), graph (Neo4j), time-series (InfluxDB, TimescaleDB), search (Elasticsearch), and vector (Pinecone, pgvector).
How It Works
Most production systems use multiple database types (polyglot persistence). A typical architecture: PostgreSQL for core business data, Redis for caching and sessions, Elasticsearch for search, Kafka for event streaming, ClickHouse for analytics.
The Decision Framework
- Relational: Tables, SQL, ACID. Best for structured data with relationships. PostgreSQL, MySQL.
- Document: JSON documents, flexible schema. Best for content, catalogs, user profiles. MongoDB, CouchDB.
- Key-Value: Simple get/set by key. Extremely fast. Best for caching, sessions. Redis, Memcached, DynamoDB.
- Wide-Column: Rows with dynamic columns. Best for time-series, event logs. Cassandra, HBase.
- Graph: Nodes and edges. Best for social networks, recommendations. Neo4j, Amazon Neptune.
- Time-Series: Optimized for timestamped data. Best for monitoring, IoT. InfluxDB, TimescaleDB.
- Search Engine: Full-text search, ranking. Best for product search, log analysis. Elasticsearch, OpenSearch.
- Vector: Similarity search on embeddings. Best for AI/ML applications. Pinecone, pgvector.
What the Industry Uses
Uber uses PostgreSQL (trips), Redis (caching), Cassandra (analytics), Elasticsearch (search).
Airbnb uses MySQL (core data), Redis (caching), Elasticsearch (search), HBase (ML features).
Discord uses Cassandra (messages), PostgreSQL (user data), Redis (presence, rate limiting).
Performance and Tradeoffs
- Generality vs Optimization: Relational databases work for most things but are not the best at anything specific.
- Operational overhead: Each database type requires different expertise for maintenance and monitoring.
- Data consistency: Using multiple databases means managing distributed consistency — changes may need to be applied atomically across stores.
Mistakes Engineers Make
- Using a single database for all use cases
- Choosing based on hype rather than access patterns
- Not considering operational complexity of managing multiple database types
Practice These Interview Questions
- What are the main types of databases?
- When would you use a document store vs a relational database?
- What is polyglot persistence?
Original DosiBridge notes for Database Types
This section is written specifically for this page, not copied from a general system-design checklist. The useful way to study Database Types is to connect the concept to a data path where correctness, access pattern, and future migrations matter more than benchmark numbers. That framing changes the design discussion from definitions to operating choices.
What makes this topic distinct
- Query Shape: For Database Types, decide the query shape before choosing tools; otherwise the design looks clean but fails when database changes.
- Write Amplification: For Database Types, decide the write amplification before choosing tools; otherwise the design looks clean but fails when types changes.
- Replication Lag: For Database Types, decide the replication lag before choosing tools; otherwise the design looks clean but fails when database changes.
- Migration Safety: For Database Types, decide the migration safety before choosing tools; otherwise the design looks clean but fails when types changes.
- Data Ownership: For Database Types, decide the data ownership before choosing tools; otherwise the design looks clean but fails when database changes.
Distinct angle: taxonomy by operational responsibility
Database types should be compared by responsibility, not popularity. A relational database protects relationships and constraints, a document store keeps aggregate-shaped records together, a key-value store optimizes direct lookup, a graph database makes relationships first-class, and a search engine optimizes retrieval. The unique SEO value here is the operational map: what each type is trusted to own and what it should not own.
Production review question
If a team adopts Database Types, what observable signal proves it helped instead of only making the architecture diagram more fashionable?
Practical metric to track
Track database-types health as a named dashboard or review item: combine one user-facing metric, one saturation metric, and one correctness metric. For Database Types, this keeps the discussion grounded in behavior that can be measured after deployment instead of generic advice that sounds good in an interview but never gets verified.
Further Reading
