Platforms & Cloud Services
The primitives first, then how BigQuery, Snowflake, ClickHouse, DuckDB and the managed streaming services realise them — architecturally, not from a feature list.
A data platform is assembled from about seven primitives. Every cloud sells all seven under different names, and the names are the least interesting part of the comparison.
Six axes that actually separate analytical warehouses — architecture, storage/compute coupling, latency profile, concurrency model, cost-model shape and workload fit — and why a product name is the last thing to decide.
A serverless analytical engine: columnar storage you do not manage, compute allocated per query rather than provisioned, and exactly two physical knobs — partitioning and clustering — carrying all the layout weight.
Three separated layers — immutable columnar storage, independently sized compute clusters, and a services layer that holds all the metadata — and what that separation actually buys, which is isolation and elasticity rather than speed.
A columnar OLAP database built for logs, events and real-time aggregates: immutable sorted parts merged in the background, a sparse index over granules, and a sort order that decides almost everything.
An analytical database that runs inside your process. No network in the hot path, no cluster, no concurrency story — and that combination changes what a pipeline stage costs, not just how fast a query is.
Managed Kafka, Kinesis, Pub/Sub and Event Hubs are all realisations of the same primitive — a durable, replayable log. The axis on which they genuinely differ, and the one that changes your design, is ordering.
Eight questions that turn "which warehouse should we use" into a list of required capabilities, two or three candidate architectures, and the trade-off each one asks you to accept. The output is never a single product.