How would you architect a multi-tenant LlamaIndex application with metadata filtering per tenant?

A multi-tenant RAG application needs to guarantee that one customer's query never surfaces another customer's data, and the architecture choice comes down to how strict that isolation needs to be versus how much operational overhead you can take on.

1. Shared index, metadata-scoped. Every Node is tagged with a tenant_id field at ingestion time. At query time, a MetadataFilters exact-match filter on tenant_id is attached to the retriever so similarity search only ever considers that tenant's Nodes. This is the most storage-efficient approach and scales well operationally, since there's only one index to manage, but it relies on the filter being applied correctly on every single query path with no exceptions.
2. Isolated indices or collections per tenant. Each tenant gets a fully separate vector store collection or index. This gives stronger isolation, since a bug in filter logic can't leak across tenants, but it multiplies operational overhead: more indices to provision, monitor, and keep in sync, and it can be less efficient for a very large number of small tenants.

A common middle ground is metadata-scoped filtering within a shared index for the majority of tenants, reserved for cases with genuinely strict compliance or data-residency requirements to isolated indices instead, and in either case enforcing the tenant scope at the lowest possible layer, such as a wrapper around retriever construction, so no code path can accidentally construct a query engine without it.