Performance Tuning — Clustering Keys and Search Optimisation
Snowflake's micro-partition pruning automatically skips irrelevant partitions for filtered queries, but only when the filter column values are clustered together in the same partitions. Data loaded via COPY INTO is initially sorted in the order it was written, which may not align with common query filter patterns. Over time, as data is inserted, updated, and merged, micro-partitions become poorly clustered: rows with the same `match_date` scatter across many partitions, forcing full scans. Clustering Keys and Automatic Clustering address this by physically sorting table data.
Performance tuning in Snowflake differs fundamentally from traditional database tuning. There are no indexes to create, no statistics to update, no buffer pool to tune, and no table partitioning to manage manually — all are handled automatically by Snowflake's Cloud Services layer. The two primary performance levers for Snowflake data engineers are clustering (controlling which columns data is physically sorted by) and result caching (exploiting Snowflake's automatic result cache to eliminate redundant query computation). Most Snowflake performance problems are solved by improving clustering alignment or reducing query complexity.
Analogy🏏Cricket
🏏 Think of it like cricket: OLTP is the IPL's live ticketing counter — it handles thousands of simultaneous seat reservations, each requiring a precise single-seat record update with immediate confirmation. Speed per transaction and data consistency under concurrent updates are everything. OLAP is the IPL's season statistics department — it runs complex analytical queries across every ball bowled in every match of every season to produce the published rankings, economy rates, and historical comparisons. No one books a seat through the statistics department, and no broadcaster calls the ticketing counter for Bumrah's career economy rate. The two workloads demand completely different systems. Just as the ticketing counter is built for speed and correctness on one seat at a time and would buckle if asked to tally a decade of attendance mid-sale, an OLTP row-store excels at single-record writes but chokes on full-table aggregation; and just as the statistics department pores over millions of past deliveries but would be hopeless at booking a live seat under contention, the OLAP columnar engine sweeps billions of rows yet is the wrong tool for a fast single-row update. The physical design of each — row-oriented for the counter, columnar for the stats desk — is what makes it superb at its own job and unfit for the other's.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.