ClickHouse partitioning

Partitioning splits a ClickHouse table into independent pieces by some expression — almost always a date truncation like toYYYYMM(date) or toYYYYMMDD(date). Each partition lives in its own set of on-disk parts, independent of others. Two big wins: partition pruning — a query with WHERE date >= '2024-01-01' only reads partitions ≥ 202401, skipping the rest at planning time (before even touching the primary index); bulk partition operations — ALTER TABLE ... DROP PARTITION '202301' instantly deletes a whole time range, O(1) on metadata, much faster than DELETE. This pairs perfectly with TTL to automate log retention. The gotcha: don't over-partition — thousands of small daily partitions hurt performance because merges and metadata operations scale with partition count. Rule of thumb: monthly partitions for long-lived data, daily only if you churn partitions daily (dropping old ones) or have genuinely huge daily volumes.