NoSQL families

"NoSQL" names several different kinds of database that are not built around relational tables. A key-value store fetches one value by its key, very fast and nothing else. A document store keeps each record as a JSON-like document that can nest lists and objects, so one read returns a whole object. A wide-column store spreads huge, sparse tables across many machines and suits heavy write streams such as events or messages. A graph database stores nodes and the links between them and follows links quickly. Each one gives up some query freedom — ad-hoc joins, transactions across many items — to scale out and stay fast on the queries it was shaped for. NoSQL does not mean no schema, always faster, or no transactions.

Use when

Very high request or write rates on a few well-known queries — look up by key, list one owner's items · Data whose shape varies from record to record, read as a whole object · Huge append-heavy streams — events, telemetry, chat messages — read back by key and time · Many-hop relationship questions — friends of friends, fraud rings — for a graph store

Avoid when

The queries aren't known yet or keep changing — a relational database answers new questions more easily · The core of the app is many-row, many-table transactions — balances, inventories, orders · The data fits comfortably in one relational database and its replicas — don't pay the modeling cost early

Trade-offs

Scale-out and steady latency on designed queries, in exchange for fewer ways to query the data · Schema flexibility moves the schema into the application code — it still exists and still has to be managed · Some stores offer transactions, but they are narrower or cost more than single-item writes · Most real systems end up using more than one store (polyglot persistence) — each adds operations work

Requires

Relational databases & indexes