Database Types

SQL vs. NoSQL frames the decision as roughly one axis — relational structure vs. flexible scale — but "NoSQL" itself covers several genuinely different data models, each shaped around a different access pattern. Knowing which model fits which problem, and naming it specifically, is a stronger interview answer than "we'll use a NoSQL database."

The main types

Type	Data model	Good for	Examples
Relational	Tables, rows, foreign keys	Complex relationships, strong consistency	PostgreSQL, MySQL
Document	Nested, semi-structured JSON-like documents	Flexible schemas, one-document-per-entity reads	MongoDB, DynamoDB (partially)
Key-value	Opaque value looked up by a single key	Extremely fast simple lookups, caching, sessions	Redis, DynamoDB
Columnar (wide-column)	Rows grouped by column families, sparse	Massive write volume, analytical scans over columns	Cassandra, HBase
Graph	Nodes and edges as first-class citizens	Deep relationship traversal (friend-of-a-friend, fraud rings)	Neo4j
Time-series	Data indexed and optimized by timestamp	Metrics, sensor data, high write rate, range queries by time	InfluxDB, TimescaleDB
Search	Inverted index over text fields	Full-text search, relevance ranking	Elasticsearch, OpenSearch

Why the model matters more than the brand name

Each type exists because it optimizes its internal storage layout around one access pattern, at the cost of being awkward or slow for others:

System Design Lab

A key-value store is fast precisely because it gives up query flexibility — it can't filter or sort by anything other than the key, but a lookup by key is close to as fast as a lookup can be, which is why key-value stores double as the storage layer for most caches, a connection worth naming when it comes up in the Caching Fundamentals module. A graph database is fast at multi-hop traversal precisely because it stores relationships as direct pointers rather than requiring a relational join at every hop — the same query ("friends of friends of friends") that gets exponentially expensive as a chain of SQL joins is comparatively cheap when the storage engine is built around walking edges.

Picking a type: match the model to the query, not the trend

The practical exercise in an interview is to look at the dominant read pattern the design actually needs and pick the model built for it:

• Need consistent, relational, transactional data with complex queries you can't fully predict upfront? Relational.
• Need to store and fetch a whole entity (a user profile, a product) as one flexible unit, with schema that varies or evolves? Document.
• Need the fastest possible lookup by a single known key, and nothing more? Key-value.
• Need to answer "who is connected to whom, how deeply"? Graph.
• Need to ingest huge volumes of timestamped data and query by time range? Time-series.
• Need to search free text with relevance ranking, not exact match? Search.

Real systems commonly use several of these side by side — a relational database for core transactional data, a key-value store for sessions and caching, and a search index for the site's search bar — rather than forcing one database type to serve every access pattern in the system.

Why this matters in an interview

Naming the specific database type — "a graph database, since the core query is multi-hop relationship traversal" — rather than a generic "NoSQL database" demonstrates you're reasoning from the access pattern to the storage engine, not from a buzzword. It also opens the door to naming a specific product, which signals real familiarity rather than textbook recall.

Using multiple specialized databases vs. one general-purpose database: pros and cons

Pros

• ✓Each data model is fast at exactly the access pattern it was built for
• ✓Avoids forcing an awkward workload (e.g. graph traversal) onto a mismatched engine
• ✓Lets each piece of the system scale and evolve independently

Cons

• ✕More operational surface area — multiple database systems to run and monitor
• ✕Data often needs to be synchronized or duplicated across systems
• ✕Team needs to understand the failure modes and tuning of more than one engine

Further Reading

• Martin Kleppmann — Designing Data-Intensive Applications, Ch. 2–3 — the deepest treatment of how different data models map to different storage engines.
• AWS — Purpose-built databases — a practical, product-grounded survey of database types and the workloads each is designed for.