Databases#
Databases are where program state lives: the operator’s intel catalog, a target’s crown jewels, a SIEM’s evidence trail. Reading the schema, the query plan, and the access controls is half the investigation; writing efficient queries against an operator-owned store is the other half.
Two lenses on the same surface. Types organises the engines by data model and workload (relational, NoSQL, search, analytics). Components walks the internal pieces every engine has (storage, indexes, query planner, transactions, WAL, replication, backup). The first lens helps pick a store; the second explains why two stores from the same type can behave very differently under load.
Types#
The four broad forms a database can take. Most systems start on a single relational engine; the other three exist when the workload genuinely needs them.
Tables, rows, joins, SQL, ACID. The default store for structured records.
Document, key-value, wide-column, graph, time-series, vector. Each subtype solves a different problem.
Inverted indexes. Elasticsearch, OpenSearch, Solr, Meilisearch.
Columnar storage and parallel execution. Warehouses, lakehouses, embedded engines.
Components#
The internal pieces every database engine builds from. The forms differ; the responsibilities do not.
Storage engine, indexes, query parser, planner, executor, buffer pool, transactions, MVCC, WAL, replication, backup, catalog.
The query language nine relational engines out of ten speak. Filed under DSLs; cross-linked here for context.
Clients, GUIs, migrations, ORMs, connection poolers, backup tooling, observability.