Liquid Clustering beats ZOrder in three of four workloads, benchmark shows in Delta Lake

What Was Tested

A benchmark published on InfoQ on October 12, 2026 compared three ways of organizing data in a Delta Lake table: Partitioning, ZOrdering, and Liquid Clustering. The author, Kushal Kumar Vishwakarma, reviewed by Renato Losio, ran four query types against a synthetic dataset of 50 million records to measure latency and the volume of data read for each strategy (source).

According to the author, the questions behind the benchmark came from real problems faced while architecting Delta Lake platforms at TCS UK (civil aerospace sector) and at IBM, on a project for Shell Maritime, where the choice of layout directly affects pipeline SLA compliance and cloud computing cost. The stated motivation is that most published comparisons come from Databricks itself or stem from theoretical reasoning, without measuring the actual behavior of queries.

The Three Strategies, in a Few Words

For those who don't deal with lakehouses on a daily basis, it's worth situating each approach before the numbers:

• Partitioning physically divides data into folders by a column (for example, txn_date), favoring sequential range scans.
• ZOrder is a Delta Lake optimization command that reorders data within files based on multiple columns, improving file pruning when the filter matches those columns exactly.
• Liquid Clustering is Delta Lake's newest technique, which organizes data using a Hilbert curve and updates clustering incrementally, without requiring manual OPTIMIZE jobs or periodic rewrites of the entire table.

The three ways of creating the table in the benchmark follow this pattern:

# Partitioned
df.write.format('delta').partitionBy('txn_date').saveAsTable('lc_partitioned')

-- ZOrdered
OPTIMIZE lc_zorder ZORDER BY (customer_id, region, txn_date)

-- Liquid Clustered
CREATE TABLE lc_liquid
CLUSTER BY (customer_id, region, txn_date)
AS SELECT * FROM source_data

The Experiment Design

The dataset simulated a retail environment with columns such as customer_id, txn_date, region, amount, and product_cat, combining uniform and skewed distributions. The skew parameters, such as Zipf α = 1.2 for customer segments and an 80/20 hot-spot split per partition, were not chosen arbitrarily: the author says he calibrated them from production telemetry, in which 20% of customer segments account for about 80% of query traffic.

The Four Scenarios and Who Won Each One

The benchmark ran four workload profiles: point lookup, time-range aggregation, multicolumn selective filter, and a large aggregation over the entire dataset.

The runtime and data-read volume numbers reinforce this pattern:

The Two Findings That Contradict Common Sense

The most striking result from the point lookup is that Liquid Clustering won while reading more bytes than ZOrder (784.86 MB versus 369.09 MB), yet it was still 49% faster than the partitioned baseline. The author's explanation is that Hilbert-curve organization groups related customer_id values within files more efficiently, reducing disk seek overhead even while reading more data.

The second finding is a hidden flaw in ZOrder: when the date column enters as a secondary or tertiary key in the clustering expression, as in ZORDER BY (customer_id, region, txn_date), time-range queries became 78% slower than a table simply partitioned by date. Sequential date values end up scattered across files, destroying the range-scan efficiency that partitioning offers for free.

Conversely, when the query filter matches the ZOrder key exactly, Liquid Clustering loses badly: in the multicolumn filter scenario, it was nearly five times slower than ZOrder, reading ten times more data (639.95 MB versus 59.03 MB).

Do my top queries consistently filter on the same two or three columns? If the answer is yes, ZOrder those columns. Otherwise, choose Liquid Clustering.

Kushal Kumar Vishwakarma, author of the benchmark on InfoQ

The Practical Decision Guide

The author sums up the choice in a diagnostic question: do your team's most frequent queries always filter on the same two or three columns, in a stable way? If so, ZOrder on those columns, with the most selective one listed first, tends to win. If not, or if query patterns are still changing, Liquid Clustering is the recommended default choice, since it wins in three of the four tested scenarios and eliminates the need to schedule OPTIMIZE manually. A Python decision-support script, along with the queries used in the benchmark, is available on the GitHub repository cited by the author.

What Still Needs to Be Measured

The author himself lists the study's limitations. The dataset is synthetic, chosen to ensure reproducibility and avoid exposing customer data, but production datasets carry schema drift, access seasonality, and domain-specific skew that can change the relative outcome between layouts. The benchmark also didn't measure write amplification cost or the computing overhead needed to maintain each layout as new data arrives, although the author notes that Liquid Clustering's incremental approach should have lower write cost than ZOrder's periodic rewrites.

Why This Matters for Data Teams in Brazil

Those who maintain Delta Lake pipelines on Databricks here, whether at banks, retailers, or insurers processing large transactional volumes, make this layout decision early and rarely revisit it. The benchmark's practical point is that the layout decision isn't a one-time choice: teams with stable, predictable queries over a few columns benefit from sticking with ZOrder, while teams with varied query patterns, a common case on data platforms shared across multiple teams, tend to come out ahead by migrating to Liquid Clustering.

The most concrete takeaway is testable right away: before locking in a layout strategy, run your workload's three main queries against Partitioning, ZOrder, and Liquid Clustering on a representative sample of your own data. As the benchmark numbers show, relying solely on bytes scanned as a performance proxy can lead to the wrong choice, since the layout that reads less data isn't always the fastest in practice.