Skip to content
Navigation

Type at least two characters. Search covers page titles, headings, tags and database names.

↑ ↓ to navigateEnter to openEsc to close0 pages
Introductionbeginner

Database Categories

The nine categories of database covered here, what distinguishes them structurally, and which problems each one was built to solve.

4 min readBeginnerUpdated Edit this page

"SQL versus NoSQL" is not a useful distinction. It groups a single-node relational engine with a globally distributed one, and lumps a cache together with a search cluster. The useful question is how an engine stores data, how it distributes it, and what it therefore cannot do.

Relational

Row-oriented storage, a fixed schema, and a query planner that can join arbitrary tables. One node accepts writes; replicas follow.

Row storage means reading a row is cheap and scanning one column of a billion rows is not. The planner means you do not have to know your queries in advance — a significant advantage that costs you predictability, since a plan can change when statistics change.

Covered here: PostgreSQL, MySQL, MariaDB.

Key-Value

A hash map addressed by key, usually held entirely in memory. No joins, no query planner, no schema — and consequently sub-millisecond operations with very predictable cost.

The defining constraint is memory. Capacity is bounded by RAM, and what happens when RAM runs out is a configuration decision you must make deliberately, not discover during an incident. See Memory Management.

Covered here: Redis, Valkey.

Document

Stores JSON-like documents and indexes their fields. A document is retrieved as a unit, so data that is read together is usually stored together.

The flexibility is real but conditional: schema enforcement moves from the database into the application, and nothing stops two documents in the same collection from disagreeing about what a field means. Index design matters as much as it does in a relational engine — arguably more, because there is no planner heuristic to save a bad query.

Covered here: MongoDB.

Column-Oriented

Values from one column are stored contiguously and compressed together. A query that touches three columns of a hundred reads roughly three percent of the data.

This is transformative for aggregation and useless for point lookups and row updates. Column stores generally implement updates as background rewrites rather than in-place modification, so an "UPDATE-heavy column store" is a design mistake, not a tuning problem.

Covered here: ClickHouse.

Wide Column

Data is partitioned by a partition key across a ring of equal nodes, and rows within a partition are sorted by clustering columns. There is no coordinator and no primary node.

Writes scale close to linearly with node count, because any node can accept any write. In exchange, you must know your queries before you design your tables: there are no joins, and a query that does not include the partition key either scans the cluster or is rejected.

Covered here: Apache Cassandra, ScyllaDB.

Distributed SQL

SQL, transactions and joins on top of data ranges replicated by a consensus protocol across nodes. Each range has a leader; writes go through it and are committed once a majority persists them.

You get horizontal write scaling without giving up transactions. You pay for it in latency — every write is at least one consensus round trip — and in operational complexity that only makes sense once a single-node engine genuinely cannot cope.

Covered here: CockroachDB, YugabyteDB.

Time Series

Optimised for append-mostly, timestamped data: automatic partitioning by time, compression tuned for slowly changing numeric values, retention and downsampling as first-class features.

The metric that determines whether a time-series deployment survives is cardinality — the number of distinct series, not the number of points. See Cardinality.

Covered here: TimescaleDB, VictoriaMetrics, InfluxDB.

Search Engines

An inverted index maps terms to the documents containing them, with an analysis pipeline that decides what counts as a term. This is what makes relevance ranking, stemming and fuzzy matching possible.

Search engines are not systems of record. They have no transactions across documents, their refresh model means writes are visible after a delay, and their memory behaviour is dominated by heap and shard count rather than dataset size.

Covered here: Elasticsearch, OpenSearch.

Embedded

A library linked into your process, storing data in local files. No network, no server process, no separate operational surface — and no replication, no concurrent writers across machines, and durability that depends on the host's filesystem behaviour.

Covered here: SQLite, RocksDB.

Reading a category as a set of constraints

Every category trades something away. The trade is what tells you whether the category fits.

CategoryBuys youGives up
RelationalJoins, constraints, ad-hoc queriesSingle-node write ceiling
Key-valueLatency and predictabilityDurability guarantees, query ability
DocumentFlexible aggregate storageCross-document consistency by default
Column-orientedScan and aggregate throughputPoint lookups, in-place updates
Wide columnLinear write scalingJoins, ad-hoc queries, read-modify-write
Distributed SQLScaling without losing SQLWrite latency, operational complexity
Time seriesRetention and compression built inGeneral-purpose querying
SearchRelevance and text analysisBeing a system of record
EmbeddedZero operational surfaceConcurrency, replication