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.

The layer above the engines (added 2026-08-31)

The spectrum above is about where data lives. Two sources now sit above all of it and treat the engines as substitutable endpoints — jitsu on the write side (an event pipeline landing data in whichever warehouse you name) and slayer on the read side (a semantic layer that stores nothing and compiles a query expression into SQL for whichever engine is behind it). Neither argues that the engine does not matter, but both are built as if it were a configuration choice, which is a different picture of the stack from the one the founding sources drew. Two sources is not a trend; it is a thing to watch.

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 · semantic-layer · slayer · jitsu · posthog-duckdb-vs-clickhouse · tinybird-clickhouse-vs-duckdb · synthesis