Analytical databases
The umbrella concept of this spoke: databases built for analytical (OLAP) queries — scans, aggregations, and joins over large columnar datasets — as opposed to transactional (OLTP) systems tuned for many small row-level reads/writes. The founding sources stake out an embedded↔distributed spectrum; a second, orthogonal axis — whether storage and compute are coupled or disaggregated — entered with the cloud warehouse.
The spectrum
- Embedded / in-process — duckdb: a library running inside your application, single machine, no server. Minimal ops; great to ~100 GB, notebooks, dev, edge, per-tenant warehousing.
- Distributed columnar (coupled) — clickhouse: shared-nothing MergeTree across nodes, for high-ingest, high-concurrency, RAM-exceeding, fault-tolerant production analytics. Compute and storage scale together.
- Cloud warehouse (disaggregated) — snowflake: compute (elastic “virtual warehouses”) and storage (object store) scale independently, delivered as a pay-per-use service. The third corner of the map.
- Managed services — tinybird and peers wrap an engine (here ClickHouse) to hide cluster ops and expose an API/serving layer, trading control for less operational burden.
The working thesis
The practitioner question is usually not “which engine wins” but “which engine for which layer of the stack” — and often the answer is both (see synthesis and the PostHog “use both” account). Embedded engines and distributed engines solve different problems and increasingly coexist in one architecture.
Boundary
This spoke owns the analytical data store itself. Distinct from cloud-wiki (the IaaS you rent to run it + pricing), platform-ops-wiki (the SRE practice of operating it in prod), and dev-tooling-wiki (serialization/wire formats that move data between systems, not store/query it).
Related
duckdb · clickhouse · snowflake · tinybird · storage-compute-disaggregation · posthog-duckdb-vs-clickhouse · tinybird-clickhouse-vs-duckdb · synthesis