A micro-partition is the unit Snowflake uses to store table data. It is an immutable, compressed, columnar file that holds roughly 50 to 500 MB of data before compression. Snowflake creates them automatically as data is loaded, so you never define them.
What is in the metadata
For every micro-partition and every column, Snowflake keeps statistics: the minimum and maximum value, the number of distinct values, and the number of NULLs. This metadata lives in the cloud services layer, so Snowflake can read it without touching the data files.
How pruning works
Imagine orders has 10,000 micro-partitions, filled in the order the rows were loaded each day. Because of that, each partition covers a narrow range of order_date.
SELECT SUM(amount) FROM orders WHERE order_date = '2025-03-01';
Snowflake checks the min and max order_date of each partition and keeps only the ones where 2025-03-01 could be inside the range. Maybe 12 of 10,000 qualify. It reads only those, and only the amount and order_date columns inside them.
Seeing it
In the query profile, the TableScan node shows "Partitions scanned" and "Partitions total". A good filter on well-organised data scans a tiny fraction. If you see 9,800 of 10,000, nothing was pruned.
Why load order matters
Pruning only works when the values you filter on are grouped in few partitions. Data loaded in date order is naturally clustered by date, so date filters prune well. If you filter on customer_id, whose values are scattered through every partition, each partition has a wide min and max range, and almost nothing is skipped. That is the case for a clustering key (next question), or for sorting the data when you load it.
One more detail: because partitions are immutable, an UPDATE or DELETE writes new partitions and retires the old ones. This is also why Time Travel works.