Snowflake

The cloud data warehouse — a multi-tenant, elastic, SQL warehouse delivered as a pay-as-you-go service, generally available since June 2015 and originally AWS-only. It anchors a third position on the spoke’s OLAP map: not embedded like duckdb, not a coupled shared-nothing engine like clickhouse, but storage-compute disaggregated. Everything below is from the SIGMOD 2016 paper (a 2016 snapshot).

The three layers (multi-cluster, shared-data)

A service-oriented architecture of independently scalable services in three layers:

Data Storage — table data and query results on Amazon S3. Table files are immutable: a write (insert/update/delete/merge) produces a new table version by adding and removing whole files, all tracked in metadata. Immutability is what makes worker-failure retries and time travel cheap.
Virtual Warehouses — the “muscle.” Elastic clusters of EC2 worker nodes, presented to one user as a virtual warehouse (VW) in abstract “T-shirt sizes” (X-Small…XX-Large) so pricing can evolve independently of the underlying instances.
Cloud Services — the “brain.” Manages VWs, queries, transactions, and all metadata (schemas, access control, encryption keys, usage stats, the pruning metadata).

Virtual warehouses: pure, elastic, isolated compute

Pure compute — a VW can be created, resized, or destroyed on demand with no effect on the database state; users are encouraged to shut down all VWs when idle (you pay per compute-hour). Compute scales independently of data volume.
Isolation — each query runs on exactly one VW; worker nodes are not shared across VWs, giving strong performance isolation, the cloud-native answer to the old “data mart” problem. Many VWs can read the same shared tables with no physical copy: shared infinite storage + private compute.
Ephemeral workers — each query spawns short-lived worker processes; because files are immutable, a worker never has externally visible effects, so failures are handled by simple retries.
Elasticity payoff — since you pay per compute-hour, a load that takes “15 hours on 4 nodes might take only 2 hours with 32 nodes” at roughly the same cost; the paper calls VW elasticity one of Snowflake’s biggest differentiators.

Why no indexes: caching + pruning

Local caching + file stealing — each worker caches the S3 file headers and individual columns it has read, on local SSD, under an LRU policy, so warm caches recover shared-nothing-like performance.
Min-max pruning instead of B+-tree indexes. Snowflake keeps per-file distribution metadata (min/max values, “zone maps” / data skipping) and, at optimization time, checks it against query predicates to skip files that can’t match — even for expressions like WEEKDAY(orderdate) IN (6,7). No user-created indexes, no tuning knobs: the “pure service” stance.

Differentiating features

MVCC + Snapshot Isolation — built on the immutable-file versioning above.
Time travel & cloning — removed files are retained up to 90 days, so earlier table versions read efficiently via SQL AT/BEFORE (absolute time, relative offset, or a prior statement ID); the same metadata powers UNDROP and zero-copy cloning.
Semi-structured / schema-less — VARIANT, ARRAY, OBJECT types (a compact self-describing binary form) with automatic schema discovery and columnar storage, making JSON/Avro “nearly as fast as plain relational data, without any user effort.”
Continuous availability across node/cluster/AZ failures, with no-downtime online upgrades — the payoff of decoupling.
End-to-end security — all data and network traffic encrypted; role-based access control at the SQL level; no user data exposed to the cloud platform.

Cross-spoke & boundary

The pricing/IaaS angle (paying AWS for the S3 + EC2 underneath) is cloud-wiki’s; here Snowflake is the database-as-subject. Built by snowflake-computing.

snowflake-elastic-data-warehouse · storage-compute-disaggregation · analytical-databases · clickhouse · duckdb · tinybird · synthesis