Types of Databases

The Uber-style product above asks a different question on every screen, and each question wants a different storage shape. Checkout wants ACID transactions (all-or-nothing writes across several rows, so a payment and its order line never disagree). The session cookie wants a microsecond key-value get: hand over one key, get one value back, no query planning. Discovery wants a search engine for text relevance or a vector index for "things similar to this". Telemetry wants a time-series append path that never has to update old rows.

Because no single engine makes all of those cheap, teams often run several side by side, a habit called polyglot persistence. The important discipline is that only one of them is the source of truth (the primary store, whose copy of a fact wins any argument). Caches and search indexes are derived from it and can be rebuilt from it, which is what makes them safe to lose. The price of every extra engine is covered by question 3 in the next section.

Interview-ready thinking therefore starts with the access pattern (which query runs most, and how fast it must be), not the brand name. The next section turns that instinct into three concrete questions and one rule of thumb.

Two flavours you will meet

A feature-rich relational engine adds semi-structured columns (JSON stored inside a table cell), full-text search, spatial extensions for geo queries, and MVCC (multi-version concurrency control, which lets readers proceed without blocking writers). A well-tuned single node handles a surprising amount of traffic; the Numbers to know table below gives the order of magnitude.

An operationally simple relational engine offers mature replication and straightforward operational patterns. Large social and marketplace workloads often pair it with sharding routers (a layer that decides which server holds which rows), read replicas, and cache layers rather than replacing it.

When relational shines

• ACID transactions are required, as in payments, orders, and inventory that must never double-count.
• Complex queries join many tables, which is exactly what analytics and reporting usually need.
• The schema must be enforced strictly, as regulated industries often demand for audit purposes.
• Relationships between entities are central to the domain, so joins are the natural query shape.

How it scales when one node is not enough

• Read replicas (read-only copies) scale read-heavy paths first, before you attempt to split writes.
• Sharding by user or tenant splits rows across servers when write or storage limits finally arrive.
• A router layer hides shard maps and tenant moves from application code, so services stay simple.

A document store keeps flexible JSON-like documents, shards them automatically (spreads them across servers by a shard key you choose), and supports rich queries inside a document. It is at its best when data varies per record, as in product catalogs, user profiles, and content management, and it can scale to very large datasets when the shard key matches how the application actually reads.

When documents shine

• The schema varies per record, such as product catalogs where attributes differ by category.
• Data is hierarchical or nested, like a user profile with its addresses embedded inside.
• Teams iterate rapidly and want schema changes without running a migration each time.
• Reads dominate and queries stay simple, with no complex JOINs across collections.

The poor fits are heavy multi-document transactions and SQL-style joins, which document engines either lack or make slow. Watch index explosion too: every query shape you want fast needs its own index, and each one taxes writes.

Two flavours you will meet

An in-memory key-value cache holds everything in RAM and answers in sub-millisecond time. Beyond plain strings it offers hashes, sorted sets, streams, and approximate counters, and it sustains very high operations per second on one node. Teams use it as a cache, a session store, a rate limiter, a pub/sub channel (publish a message once, every subscriber receives it), and a leaderboard. Clustered deployments scale by partitioning keys across nodes.

A managed key-value table is a hosted, partitioned table with low-latency keyed access. It reaches very high request rates when keys distribute evenly across partitions, capacity can be provisioned up front or driven by demand, and global replicas support multi-region patterns.

When key-value shines

• Caching sessions, API responses, or computed results that are expensive to produce again.
• Simple lookups by primary key, such as loading one user profile by its ID.
• High throughput with low latency, where a sub-millisecond response is the actual requirement.
• Real-time features such as leaderboards, rate limiting, and counters that update constantly.

The poor fit is using it as the primary store for ad hoc relational queries or relevance search: there is no planner to answer a question you did not key for in advance.