A 6 TB events table is partitioned by `customer_id`. Queries are slow and the storage layer complains. What is wrong?

What the interviewer is testing

Whether you know that partition column choice must follow query patterns and cardinality, not intuition about how data is "grouped".

What is wrong

Cardinality. With, say, 200,000 customers, this creates 200,000 partitions. Each holds a tiny fraction of the data, so you get the small file problem at scale — enormous metadata, slow planning, and per-file overhead dominating every query.

Query mismatch. Analytical queries on an events table are almost always filtered by time ("last 30 days"), not by a single customer. A time-filtered query against customer-partitioned data must scan every partition, so pruning never engages and the partitioning provides no benefit while imposing all the cost.

The fix

Partition by date — daily or monthly depending on volume — because that is how the data is actually filtered, and it produces a manageable partition count with substantial pruning.

Cluster or sort within partitions by customer_id, which gives efficient customer lookups through file-level statistics and data skipping, without creating a partition per customer. This is the key insight: partitioning and clustering are different tools, and high-cardinality access patterns belong to the second.

Then compact the existing mess and repartition the table, which is a one-off migration to plan.

The general rule

Aim for partitions in the region of hundreds of megabytes to a few gigabytes.

What a strong answer adds

Checking the query log before choosing, rather than reasoning about it. The actual filter predicates are recorded and settle the question definitively — and they frequently differ from what the team believes.

Common weak answers

Adding more compute. Sub-partitioning further, which worsens the cardinality problem.