Micro-partition

A micro-partition is the storage unit Snowflake divides every table into. Snowflake’s documentation describes micro-partitions as contiguous units of storage, each holding between 50 MB and 500 MB of uncompressed data, created automatically in the order data is inserted or loaded. Nobody defines them, and nobody maintains them.

Product details below were checked against Snowflake’s documentation in September 2026.

What is inside, and what is recorded about it

Within a micro-partition, each column is stored and compressed independently — the columnar storage layout. Alongside the data, Snowflake keeps metadata for every micro-partition, including the range of values of each column and the number of distinct values.

That metadata is what makes queries fast. Given a filter such as order_date = '2026-02-01', the engine checks each micro-partition’s recorded range for order_date and skips every one whose range cannot contain that value, without reading it. Within the micro-partitions that remain, it reads only the columns the query needs. This is pruning, done without anyone choosing a partition key.

How it differs from traditional partitioning

Snowflake’s documentation contrasts micro-partitions with static partitioning, where a column is chosen in advance and data is physically separated by its values. Micro-partitions are derived automatically, they are small enough to make DML efficient, and their value ranges are allowed to overlap, which avoids the skew a poorly chosen partition key produces. Because metadata exists for every column, a filter on any column can potentially prune — not only one designated column.

Automatic is not the same as optimal

Metadata can only exclude a micro-partition whose range misses the filter. How often that happens depends on how values are laid out:

• Rows loaded in date order produce micro-partitions that each cover a narrow date range, so a date filter skips most of them.
• A column whose values arrive in no particular order gives every micro-partition a range spanning most possible values, and a filter on it skips almost nothing, even though the metadata is there.

Snowflake measures how much micro-partitions overlap for given columns as clustering depth. When no ranges overlap at all, the documentation calls the micro-partitions constant: clustering cannot improve them further.

Load order sets the default layout. To change it, a table can be given a clustering key — columns or expressions that Snowflake uses to co-locate similar values in the same micro-partitions. The documentation is clear that clustering keys are not intended for all tables, because initially clustering the data and maintaining it cost compute and storage; they suit very large tables, typically multiple terabytes, whose queries have slowed. The test of whether one is worth it is the query performance that improves, not the metric.

How micro-partitions fit into Snowflake’s storage layer, and what the rest of the architecture bills for, is worked through in Snowflake Architecture: Three Layers and What Each One Bills For.

References: Snowflake Documentation, Micro-partitions & Data Clustering; Snowflake Documentation, Clustering Keys & Clustered Tables.