Does liquid clustering preserve auditable tenant separation in a shared Delta table architecture?

[batch_bender]

We’re evaluating a multi-tenant Databricks architecture and considering Liquid Clustering on shared Delta tables. Our concern is that tenant SLAs require data separation for audit/compliance purposes.

I’m trying to understand whether Liquid Clustering is compatible with environments where tenant data must remain demonstrably isolated, or whether this becomes a logical-vs-physical isolation issue that would require separate tables/catalogs/storage per tenant.

Has anyone dealt with this tradeoff in practice?

[balajij8]

Liquid Clustering aims to maximize read throughput and minimize data skew. It is critical not to combine performance optimization aspect-based features with security boundaries when designing for strict regulatory compliance cases.

You can follow the pattern of Catalog per tenant or Schema per tenant as they are bound to distinct storage locations via Unity Catalog.

You can enable Liquid Clustering inside each tenant's isolated tables (under Catalog/Schema) to maintain performance & SLAs but using it as a mechanism to achieve tenant separation is a bad practice leading to compliance issues.

[batch_bender]

If partitioning by tenant is considered acceptable for our audit/SLA requirements, would Liquid Clustering be viewed differently, or are they both effectively storage-layout optimizations rather than true isolation boundaries?

[Ashwin_DSA · Accepted solution]

Hi @batch_bender,

I think the key distinction is between data layout for performance and isolation as a control boundary.

My view is that Liquid Clustering should not be presented as a tenant-isolation mechanism. The official docs describe it as a data layout optimization that replaces partitioning and ZORDER to improve skipping, maintenance, and adaptability. In other words, it is primarily about how data is organised for query performance, not about creating a hard tenant boundary.

If your question is whether partitioning by tenant_id is fundamentally different, the answer is that it provides stronger physical grouping than Liquid Clustering. However, it is still not the same as hard isolation.

With Hive-style partitioning, rows for a given partition value are written under partition-specific paths/directories. That can make it easier to reason about where a tenant’s data lives and can be helpful for some operational or audit discussions.

With Liquid Clustering, Databricks explicitly positions it as a replacement for partitioning for layout/performance reasons, and the docs call out its flexibility as the main advantage.... for example, you can change clustering keys without the same rigid coupling you get with partitioning. See the official liquid clustering docs and the announcement blog.

So if the requirement is "optimise reads/writes on shared multi-tenant tables," Liquid Clustering is often the better fit. If the requirement is "demonstrate that tenant data is physically segregated as an isolation boundary," I would be cautious about treating either partitioning or Liquid Clustering as the actual control.

That last point is the most important one.

In practice, I’d describe the options like this:

Shared table + Liquid Clustering

• Good for performance and operational simplicity
• Best viewed as a layout optimisation
• Not something I would rely on as the primary evidence of tenant isolation

Shared table + tenant partitioning

• Still primarily a storage layout technique
• Gives you more obvious physical grouping by tenant than Liquid Clustering
• May be acceptable in some environments if the audit requirement is really about coarse physical separation plus access controls
• But I still would not call it a hard isolation boundary in the same way as separate tables/storage

Separate table / schema / catalog / storage location per tenant

• This is the cleaner answer when the requirement is true demonstrable isolation, reduced blast radius, or customer-specific boundary enforcement

So to answer the original question directly... if partitioning by tenant is already considered acceptable by Audit/SLA interpretation, then Liquid Clustering is still usually viewed differently. Partitioning can support a "physically grouped by tenant" argument in a way that Liquid Clustering generally does not. But from a strict architecture perspective, both are still data-layout mechanisms, not the same thing as a hard tenant isolation boundary.

One other public datapoint that may matter depending on the use case... the Delta Sharing docs explicitly call out some current limitations around sharing liquid-clustered tables with partition filtering. That is another hint that Liquid Clustering and partition-style tenant boundary semantics are not interchangeable today.

Hope this helps.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.