For tables ranging from 1 KB → 5 TB, you’ll usually end up with a mixed strategy. LC is not “all or nothing”; it shines when the physical size + update pattern justify the clustering overhead.

Use Liquid Clustering when:

• clustering keys have natural selectivity (e.g., customer_id, timestamp)

• MERGE/DELETE/UPDATE operations happen regularly

• the table grows continuously

• multiple teams access different slices of the data

• you want predictable performance without manual tuning

Avoid Liquid Clustering when:

• data is tiny

• table rarely changes

• workload is sequential full scans

• cluster-by keys have low cardinality