Snowflake5 billion queries a day · no indexes← → panels  ·  P present  ·  D draw  ·  alt+scroll or +/- zoom  ·  0 reset  ·  F fullscreen  ·  00 / 18
00COLD OPEN SIGMOD 2016 · NSDI 2020 · Snowflake engineering biggest software IPO in history

THE DATABASE THAT BROKE EVERY RULE

Five billion queries a day, no indexes, and files that are never modified. All of it falls out of one decision made in a small office in San Mateo in 2012.

CLOUD OBJECT STORAGE · ONE COPY OF THE DATA
stateless compute · rented by the second
one network hop in between
$90Bcompany
0indexes

three things that sound wrong

No indexes. Not missing — removed on purpose.

No file is ever modified. Not once, ever.

UNDROP TABLE. One command and the table is back.

the one decision · 2012

Every warehouse before Snowflake kept compute next to the data. Three engineers pulled them apart and put the data on the far side of a network.

Everyone said the same thing: far too slow.

They moved the data away from the compute — and ended up faster than the databases sitting on top of theirs.

100%
01THE OLD WORLD shared-nothing · Teradata · Netezza · Vertica · Redshift 1990s – 2012

ONE RULE: MOVE COMPUTE TO THE DATA

Teradata, Netezza, Vertica, the original Redshift. Every machine owned a slice of the data on its own local disk, because networks were slow and local disks were not.

SHARED - NOTHING · EVERY MACHINE OWNS ITS OWN SHARD
one heavy ETL job · everyone slows down
cpu + memory
its own local disk
× 20 machines · one shared cluster

SCALING

Add five machines and terabytes have to be redistributed before they are useful. Days of reshuffling, degraded the whole time.

CONTENTION

ETL, dashboards, reports and ad-hoc SQL all fight over one pool of CPU. One heavy job slows down everyone.

OVERPROVISIONING

The cluster is sized for end-of-quarter peak. The rest of the year that compute sits idle.

Three different problems, one cause: storage and compute can never scale independently.

100%
02WHY NOW San Mateo, 2012 · Oracle + CWI Amsterdam Dageville · Cruanes · Żukowski

THE ASSUMPTIONS EXPIRED

Separating storage from compute was not a new idea. It was an uneconomic one — until three things changed at roughly the same time.

compute + disk · fused
compute · disposable
storage · one copy
2012

1 · cloud object storage matured

S3: eleven nines of durability, effectively unlimited, and cheap enough to build a database on top of.

2 · data-centre networks got fast

Reading over the network stopped being catastrophically slower than reading a local disk.

3 · compute became elastic

Rent machines for minutes, throw them away, spin up new ones on demand.

Most people saw better infrastructure. Three engineers saw permission to redesign the warehouse from first principles.

100%
03ANATOMY SIGMOD 2016 · NSDI 2020 · Snowflake engineering the anchor diagram

THREE LAYERS, SEPARATELY SCALED

Storage at the bottom, disposable compute in the middle, one always-on brain above both. Every query starts at the top and works its way down.

3 · CLOUD SERVICES
2 · VIRTUAL WAREHOUSES
1 · STORAGE

the brain

Always on, shared by every customer. Plans the query, prunes files, schedules work, commits transactions.

rented by the second

Clusters that hold no data — they appear and vanish at any moment, in any size.

one copy of the truth

Object storage. Every table lives here and only here, as thousands of immutable files.

This is the whole architecture. Everything after this panel is a consequence of it.

100%
04MICRO-PARTITIONS SIGMOD 2016 · NSDI 2020 · Snowflake engineering 50 – 500 MB per file

A TABLE IS THOUSANDS OF FILES

Snowflake slices every table into small columnar files, then records a handful of statistics about each one.

one logical table
thousands of immutable files
50 – 500 MB each
stored column by column

and for every column, in every file

MIN value  ·  MAX value  ·  distinct count  ·  null count

A few hundred bytes per file. This is what the next two panels are built on.

A large production table is tens of thousands of these. Snowflake slices them automatically — nothing to configure.

The data matters less than what Snowflake writes down about it.

100%
05IMMUTABILITY SIGMOD 2016 · NSDI 2020 · Snowflake engineering write-once storage

NEVER UPDATE A FILE. UPDATE THE LIST.

Once a micro-partition is written it is never modified again. Every write produces new files and a new version of the list that names them.

TABLE · version 1
TABLE · version 2
UPDATE one row
the old file · still there, untouched
a brand-new file

a table is a list of files

Objects in S3 are write-once. You can create them or replace them whole — you cannot edit part of one.

So UPDATE never touches the file. Snowflake writes a new file and swaps one entry in the list.

Change the list and you have changed the table. Keep the old list and you have kept the old table — the whole trick behind the next two panels.

The data is boring on purpose. All the movement happens in the list.

100%
06PRUNING SIGMOD 2016 · NSDI 2020 · Snowflake engineering 0 indexes

NO INDEXES. KNOW WHERE THE DATA ISN'T.

Standard Snowflake tables carry no indexes at all. Before a single byte is read, the min and max values on every file throw most of the table away.

min / max metadata · no index, no scan
WHERE order_date = 2024-03-03
50,000files in the table
200files actually read
Jan 1 – Jan 9 · cannot contain March 3
Mar 1 – Mar 7 · might contain it
An index says where the data is. Snowflake's metadata says where it is not.

99% of the table is eliminated in the metadata layer — before the query ever reaches storage.

100%
07TIME TRAVEL SIGMOD 2016 · NSDI 2020 · Snowflake engineering up to 90 days

THE PAST IS STILL ON DISK

Dropping a table does not delete anything. It removes the current pointer — and the older pointers are still sitting there.

3 days ago
yesterday 4 PM
this morning
1 minute ago
now
DROP TABLE
UNDROP TABLE · restores the pointer

time travel

Every change keeps the previous version of the list — 1 day by default, up to 90 days on higher editions.

Ask for the table as it was yesterday at 4 PM and Snowflake reads yesterday's list. The files never moved.

Backups, snapshots and point-in-time recovery are usually three separate systems. Here they are the same mechanism, seen from three angles.

One decision — never modify data — paid for Time Travel, UNDROP and snapshot isolation at once.

100%
08ZERO-COPY CLONE SIGMOD 2016 · NSDI 2020 · Snowflake engineering CLONE · one command

A HUNDRED TERABYTES, COPIED INSTANTLY

Cloning a production warehouse used to mean copying a production warehouse. Here it means writing one new list.

PRODUCTION · 100 TB
CLONE · created in seconds
both tables point at the same immutable files
a new file — written only when the clone diverges
0bytes copied
100 TBcloned in seconds

copy-on-write, for a warehouse

CLONE writes a new version of the metadata pointing at the same files. Nothing is duplicated.

Only when one side changes does Snowflake write new files for the parts that differ.

The same idea as Replit's millisecond sandbox snapshots — applied to a database measured in hundreds of terabytes.

Nothing is copied. Two tables simply share the same storage until one of them changes.

100%
09VIRTUAL WAREHOUSES SIGMOD 2016 · NSDI 2020 · Snowflake engineering XS → 6XL · per-second billing

COMPUTE THAT HOLDS NOTHING

Every workload gets its own cluster, sized independently, all reading the same single copy of the data.

ETL PIPELINE
XS · 8 nodes
BI DASHBOARDS
L · auto-scaling
DATA SCIENCE
XL · burst
same data · separate CPUs · zero contention

the old world

One cluster for everyone. A heavy ETL job slowed the dashboards, and ad-hoc queries collided with scheduled reports.

auto-suspend · auto-resume

A warehouse spins up in seconds, suspends when idle, resumes on the next query — and bills by the second.

A warehouse holds nothing. Kill one mid-query and you lose the query — not one byte of data.

Snowflake does not schedule competing workloads more cleverly. It gives each one its own machines.

100%
10THE OBJECTION SIGMOD 2016 · NSDI 2020 · Snowflake engineering far data · near-local speed

ISN'T OBJECT STORAGE SLOW?

The data sits on the far side of a network, and cloud storage is much slower than a local disk. Four layers hide it.

1 · READ LESS
pruning throws away 99%
2 · READ NARROWER
3 columns, not 300
3 · READ LOCALLY
warm local SSD cache
4 · DON'T READ
result cache · instant
100% of the table
1% survives pruning
0 reads on a cache hit
Snowflake never fixes object-storage latency — it stacks four ways of not paying it.

The fastest read is the one you never do. Everything else is making the remaining reads smaller.

100%
11ELASTICITY Building An Elastic Query Engine on Disaggregated Storage NSDI 2020 · 70M queries

RESIZE WITHOUT MOVING THE DATA

You scale a warehouse precisely when it is already busy — the worst possible moment to push terabytes across the network. So Snowflake doesn't.

4 nodes · each owns a slice of the cache
resized to 8 · ownership moves instantly
RESIZE
The cache is not rebalanced. Only ownership changes now; the cached data migrates later, as queries read files under the new assignment. Lazy consistent hashing.
node A · finished early
node B · slow disk, noisy neighbour
A steals B's remaining files

Ownership is cheap to move. Data is not. Move the cheap thing now and the expensive thing never.

100%
12THE BRAIN SIGMOD 2016 · NSDI 2020 · Snowflake engineering always on · multi-tenant

THE LAYER THAT KNOWS WHAT A TABLE IS

Storage holds files. Compute runs plans. Something still has to know which files make up which table, at which version, for whom.

PARSE
PLAN
PRUNE
SCHEDULE
COMMIT
every query starts here
virtual warehouses · they only execute

the control plane

Multi-tenant and always running, shared across every customer. It is the only layer that knows what a table is.

what the other layers know

Storage knows only about immutable files. Compute knows only how to execute a plan. Neither knows which files belong to which table.

All of it happens before a single warehouse is touched.

Cloud Services is the control plane for the entire system — and every query passes through it.

100%
13UNDERNEATH SIGMOD 2016 · NSDI 2020 · Snowflake engineering FoundationDB

A DATABASE UNDER THE DATABASE

Object storage is perfect for immutable files and useless for metadata, which changes on every transaction. So the metadata lives somewhere else entirely.

OBJECT STORAGE · PETABYTES · NEVER MODIFIED
FoundationDB
distributed transactional key-value store
the data · huge, simple, write-once
the metadata · small, complex, transactional
file lists · table versions · pruning stats · transaction state

commit does not move data

By the time you COMMIT, the new micro-partitions are already written to object storage.

The commit changes one record in FoundationDB — the table now points at a new version of its file list.

Apple acquired FoundationDB in 2015 and pulled the distribution. Snowflake kept its own copy until it was open-sourced in 2018.

A transaction does not move the data. It moves a pointer.

100%
14END TO END SIGMOD 2016 · NSDI 2020 · Snowflake engineering one query, five steps

THE JOURNEY OF ONE QUERY

Everything in the last ten panels, in the order it actually happens.

1 · parsed, planned, pruned
2 · plan sent to a warehouse
3 · cache miss reads storage
4 · cache hits read local SSD
5 · result returned and cached
tens of thousands of files → a few hundred
any node that falls behind gets its files stolen
secondsyou pay for exactly these
No index was consulted. No data file was modified. Compute stayed completely separate from storage — and the warehouse suspends itself a few minutes later.

Metadata first, storage last, and as little of storage as possible.

100%
15THE PRICE OF AN ARCHITECTURE NYSE: SNOW · first-day close Sept 16, 2020

WHAT THE MARKET ACTUALLY BOUGHT

Snowflake's IPO was the largest software listing ever, and Berkshire Hathaway broke a sixty-four-year habit to take part in it.

$120
offer price
$254
first-day close
$730M
Berkshire buys in
$1.5B
worth by the close
one trading day
$3.4Braised · biggest software IPO ever
~$70Bcompany by the end of day one
Per-second billing exists because compute is disposable. Elastic scaling, because the data lives somewhere else.

Features can be copied. The architectural decisions that made those features possible are much harder to copy.

100%
16TRADE-OFFS SIGMOD 2016 · NSDI 2020 · Snowflake engineering nothing is free

EVERY DECISION MOVES THE COMPLEXITY

None of this is free. Each choice makes one part of the system simpler by making another part carry the weight.

time travel
zero-copy clone
snapshot isolation
pruning
permissions
one small metadata layer
storage: remarkably simple

immutable files

Reads get simple. Writes get expensive — changing one row rewrites a whole file.

separated storage

Warehouses become disposable. Every query pays a network hop that caching has to hide.

no indexes

Point lookups eventually forced them back in another form — Search Optimization and Hybrid Tables.

The storage layer is simple on purpose. The metadata layer is where all the difficulty went.

100%
17LESSONS SIGMOD 2016 · NSDI 2020 · Snowflake engineering take these with you

FIVE THINGS WORTH STEALING

None of these are specific to data warehouses.

1
architecture follows economics
Every rule you inherited was optimised for someone else's constraints.
2
immutability is a feature factory
One decision produced Time Travel, UNDROP, cloning and snapshot isolation.
3
simple data, smart metadata
Transactions become pointer updates. Clones become pointer copies.
4
elasticity starts with statelessness
If compute owns no state, it can appear and vanish at any moment.
5
architecture is strategy
Competitors copy features. Copying the decisions underneath is much harder.
five things you can take into your own systems

Great architectures do not maximise features. They maximise consequences.

100%
18THE WHOLE STORY SIGMOD 2016 · NSDI 2020 · Snowflake engineering consequences

NOT SEVEN FEATURES. TWO DECISIONS.

Time Travel, cloning, snapshot isolation, stateless compute and even the pricing model all feel connected because they are.

separate storage from compute
never modify a file
two decisions
time travel
UNDROP
zero-copy clone
snapshot isolation
elastic warehouses
per-second billing
the marketplace
consequences, not separate inventions

and the industry followed

Amazon rebuilt Redshift around separated storage. Databricks built the Lakehouse on the same principle. Aurora and Neon are moving the same way.

but not for everyone

Roblox reached the opposite conclusion and built their own cloud — at their scale, owning the infrastructure was cheaper than renting it.

Architecture is not about following best practices. It is about optimising for today's economics — and the best design is rarely universal.

What looked far too slow a decade ago is now just modern cloud architecture.

100%