How does Weaviate's multi-tenancy isolate tenant data on disk?

Rather than storing every tenant's objects together in one shared collection-wide storage area distinguished only by a tenant ID field (which would still leave data physically commingled), Weaviate allocates each tenant its own distinct physical segment on disk within the collection.

This physical separation, rather than purely logical separation via a filter, is what gives Weaviate's multi-tenancy a stronger isolation guarantee: a query scoped to one tenant genuinely only reads that tenant's own on-disk segment, rather than scanning shared storage and relying entirely on a filter condition to exclude other tenants' data, reducing both the risk of a filtering bug leaking cross-tenant data and the performance cost of scanning irrelevant tenants' data that a purely logical, unpartitioned approach would incur.

This physical isolation is also what makes per-tenant index-type flexibility possible: since each tenant's data genuinely lives in its own segment, each can independently use Flat, Dynamic, or HNSW indexing appropriate to that specific tenant's data volume, rather than the whole collection being forced into one uniform index strategy regardless of how differently sized individual tenants actually are.