NoSQL families and the product map
We'll cover the following
Five NoSQL families
| Family | Examples | Best for |
|---|---|---|
| Key-value | DynamoDB, Redis, Riak | Lookup by key (URL shortener, sessions, cache) |
| Wide-column | Cassandra, HBase, Bigtable | Massive writes, time-series, event logs |
| Document | MongoDB, Couchbase, Firestore | Self-contained JSON objects, flexible schema |
| Graph | Neo4j, Neptune | Relationship traversal (friends of friends) |
| Search | Elasticsearch, OpenSearch, Solr | Full-text search, filters, log analytics |
DynamoDB is key-value that can also hold documents. Cassandra is wide-column. Mongo is the true document store, but its sweet spot is flexible documents, not raw write throughput. Cassandra and DynamoDB are the write-heavy champions.
Relational and distributed SQL
- Relational: Postgres, MySQL, MariaDB, Oracle, SQL Server, SQLite.
- Distributed SQL: Spanner (Google), CockroachDB, YugabyteDB, TiDB.
- Vitess is a sharding layer over MySQL (YouTube, Slack), not a database itself.
- Aurora scales reads and storage well, but writes still go through one primary.
Google lineup
| Google product | Category | Cousin |
|---|---|---|
| Firestore (Datastore merged in) | Document store | MongoDB, DynamoDB |
| Bigtable | Wide-column | Cassandra, HBase |
| Spanner | Distributed SQL | CockroachDB |
| Cloud SQL / AlloyDB | Managed relational | Postgres, MySQL, Aurora |
| Memorystore | Cache | Redis |
| BigQuery | Analytics warehouse (OLAP) | Redshift, Snowflake |
BigQuery scans billions of rows to aggregate (OLAP). The others serve app traffic (OLTP). This very app uses Firestore.
Elasticsearch / OpenSearch
- A distributed wrapper (sharding, replication, REST API) around Lucene, which builds and queries an inverted index: word to list of documents containing it. That is why search is fast.
- Two jobs: user-facing search (product search, "search messages") and ops/log analytics (ELK, Splunk-style).
- Never the source of truth. Pattern: Postgres or DynamoDB is truth, changes stream via Kafka or CDC into Elasticsearch as a searchable copy.
Wide-column: when and why
- Time-series and events (IoT readings, metrics, logs): "all readings for sensor X, last hour".
- Activity feeds and message history: "all messages in chat Y, newest first".
- Huge write throughput with multi-region replication; no single primary, any node accepts writes.
- Fast writes because of the LSM-tree: append to memory, flush sequentially, no random seeks.
- Model around the query: partition key picks the node, clustering key sorts rows inside the partition. One query pattern, one table, duplicates are fine.
- Trade-offs: no joins, awkward reads outside the partition key, tunable (eventual by default) consistency.
Key-value: Redis vs DynamoDB
| Redis | DynamoDB | |
|---|---|---|
| Storage | In memory (fast, bounded by RAM) | SSD-backed disk |
| Latency | Sub-millisecond | Single-digit ms |
| Durability | Optional, weaker | Strong, replicated |
| Scale | Bounded by memory, clustering is more work | Practically unlimited, auto-partitioned |
| Role | Cache, sessions, rate limiters, leaderboards | Primary database |
Redis also has rich value types (lists, sets, sorted sets, counters). URL shortener: DynamoDB as source of truth, Redis in front for hot URLs.
Can a key-value store query by attribute?
- Scan: reads everything. Slow and costly, never on a hot path.
- Secondary index (GSI): a second copy keyed by the field. Fast lookups, extra storage and writes, eventually consistent.
- Sort key / range queries: partition key + sort key, e.g. all orders for a user between two dates.
- Ship to Elasticsearch for arbitrary filters and text search.
Rule: key-value works when you know your queries up front. The more ad-hoc the queries, the more you drift toward Postgres or Elasticsearch.
Summary: say it in the interview
- "Write-heavy, time-ordered, known query patterns: Cassandra."
- Six names cover almost every design: Postgres, DynamoDB, Cassandra, Redis, Elasticsearch, Spanner.