If you learned Delta Lake a few years ago, you learned to partition tables and run Z-order to speed up queries. Databricks now recommends liquid clustering instead, for essentially all new tables. Here is what changed and what the exam expects you to know.
Last updated July 2026.
Liquid clustering replaces both partitioning and Z-order. You declare CLUSTER BY (cols) once, and Delta co-locates related rows so queries skip files they do not need, without the rigid folder structure of partitions or the periodic rewrite of Z-ordering. Databricks documentation recommends liquid clustering over Z-ordering for all new tables, and instead of partitions for most tables.
Both older techniques work, but both have sharp edges the exam likes to probe.
Partitioning splits a table into physical folders by column value (for example one folder per date). Pick a column with too many distinct values and you get over-partitioning: thousands of tiny files and slower queries, not faster ones. Databricks guidance is blunt about the threshold: do not partition tables under 1 TB, and only partition on a column if you expect each partition to hold at least 1 GB. Worse, the partition columns are baked into the table layout, so changing your mind means a full rewrite.
Z-order (via OPTIMIZE ... ZORDER BY) improves data skipping without folders, but it is a maintenance command you have to schedule and re-run as data lands. It is also incompatible with clustering: you cannot use Z-order and liquid clustering on the same table.
You set clustering keys at create time or add them later:
CREATE TABLE t (...) CLUSTER BY (region, event_date) defines the keys up front.ALTER TABLE t CLUSTER BY (customer_id) changes the keys with no full rewrite. New data reorganizes as it arrives, so your layout can evolve with your query patterns.CLUSTER BY AUTO lets Databricks choose and adapt the clustering columns over time, using predictive optimization to learn from how the table is actually queried.On Unity Catalog managed tables, predictive optimization can run the maintenance work (OPTIMIZE, clustering, and VACUUM) automatically, so you stop babysitting scheduled jobs. That combination, declarative keys plus automatic maintenance, is the whole reason the recommendation shifted.
| Liquid clustering | Partitioning / Z-order | |
|---|---|---|
| How you declare it | CLUSTER BY (cols) or CLUSTER BY AUTO | PARTITIONED BY (cols) and/or OPTIMIZE ZORDER BY |
| Change keys later | Yes, no full rewrite | Partition columns are fixed; changing them rewrites the table |
| Small-file / skew risk | Managed for you | High if the partition column is chosen poorly |
| Maintenance | Can be automatic (predictive optimization) | Z-order is a command you schedule and re-run |
| Databricks guidance | Recommended for new tables | Contrast case; partition only very large tables by a coarse column |
Sourced from the Databricks docs pages "Use liquid clustering for tables" and "When to partition tables on Databricks."
The Databricks Data Engineer Associate exam reflects current guidance, so treat liquid clustering as the default answer for data layout and physical optimization questions.
Exam tip: If a question asks how to speed up queries on a table whose access patterns change, or how to avoid a full rewrite when the layout needs to change, the answer is almost always CLUSTER BY. Partitioning and Z-order are the distractors, correct only for the narrow "very large table, coarse column" case.
Do not memorize partitioning as the go-to optimization the way older study material teaches it. Know that it still exists, know the 1 TB and 1 GB thresholds, and know that liquid clustering is what Databricks now points you to first.
No. Liquid clustering replaces partitioning for that table. You also cannot combine liquid clustering with Z-order on the same table; clustering and Z-ordering are mutually exclusive.
Rarely, and only for large tables partitioned on a coarse, low-cardinality column where each partition holds at least 1 GB. Databricks recommends not partitioning tables under 1 TB at all.
It lets Databricks select and adapt the clustering columns over time based on your actual query patterns, using predictive optimization, rather than you fixing the keys manually.
On Unity Catalog managed tables, predictive optimization can run OPTIMIZE, clustering, and VACUUM automatically. You can still run OPTIMIZE manually, but the point of the newer approach is that you do not have to schedule it.
Liquid clustering and predictive optimization get their own chapter in the Associate course, with the exact CLUSTER BY syntax and the questions the exam builds around it.
Open the Liquid Clustering chapter →