A Delta Lake benchmark finds ZOrder 78 percent slower than date partitioning

A ZOrdered Delta Lake table that looks fine on bytes scanned can be serving time-range queries 78 percent slower than a plain date-partitioned table would. Kushal Kumar Vishwakarma, a data engineer who has worked on Delta Lake platforms at TCS UK and IBM on behalf of Shell Maritime, published the measurement in InfoQ after running four workload types across three layout strategies on a 50 million record synthetic dataset. The slowdown appears whenever the date column is not the first key in the ZOrder clustering expression.

The benchmark compared Databricks' Liquid Clustering, ZOrdering, and simple partitioning across four workload types: point lookup, time-range aggregation, multi-column selective filter, and large aggregation. Vishwakarma reports two findings that run counter to how these layouts are usually described in the documentation.

The two failure modes

On a time-range aggregation workload, the ZOrdered table took 1.845 seconds against the date-partitioned table's 1.038 seconds, 78 percent slower. The clustering key was (customer_id, region, txn_date), which puts the date column third. "Sequential date values are dispersed across files, destroying the daterange scan efficiency that simple partitioning provides for free," Vishwakarma writes.

On a multi-column selective filter where the query predicate matched the ZOrder key exactly, Liquid Clustering took 2.967 seconds against ZOrder's 615 milliseconds, which is almost five times slower, and scanned 639.95 MB of data against ZOrder's 59.03 MB, or ten times more. Liquid Clustering wins on the other three workload types: point lookup at 1.003 seconds against the partitioned baseline's 1.972 seconds, time-range at 659 ms against partitioning's 1.038 seconds, and large aggregation at 659 ms against partitioning's 1.038 seconds. Databricks has described Liquid Clustering as a sensible default; the paper reports where it is not.

Bytes scanned is not latency

A side result Vishwakarma calls out as counter-intuitive: on the point-lookup workload, Liquid Clustering was the fastest layout (1.003 seconds) while reading more raw data than ZOrder (784.86 MB against 369.09 MB). The explanation he gives is that Liquid Clustering packs related rows closer together inside each file, which cuts disk-seek overhead by more than ZOrder's smaller read saves. A team that watches bytes scanned as a performance proxy on a Databricks dashboard will read the wrong signal when choosing between these layouts.

What a reader has to do

The paper's own recommendation is to answer one question before picking a layout: do the top queries consistently filter on the same two or three columns? If yes, ZOrder on exactly those columns, with the most selective column first. If no, or if the query pattern will change, use Liquid Clustering, which wins on three of four workloads and removes the manual OPTIMIZE and periodic full-table rewrites that ZOrder needs.

A team that currently ZOrders on a multi-column key where date is not the first column should run its own top three time-range queries against the partitioned version of the same table before trusting the ZOrder result. Vishwakarma states a caveat: the benchmark used a synthetic dataset for reproducibility, and real production tables carry schema drift, access-pattern seasonality, and domain-specific skew that could shift the numbers. He did not measure the write-amplification cost of maintaining each layout as new data arrives, which is where Liquid Clustering's incremental approach is likely cheaper than ZOrder's periodic full-table rewrites. The dataset generator, SQL queries and a Python decision helper are published on GitHub so another team can repeat the run on its own data.

Source

The article is on InfoQ, reviewed by Renato Losio. The methodology, workload definitions, SQL and a decision helper are linked from the piece to GitHub.