What is multi-tenancy in a vector database?

Multi-tenancy in a vector database is an architecture that stores many isolated datasets — one per customer, workspace, or project — inside a shared cluster and usually a shared collection schema, so each tenant gets private vectors and indexes without spinning up a separate database per tenant.

Why is multi-tenancy harder for vectors than for plain rows?

A naive approach puts every customer’s embeddings in one giant HNSW graph and filters by a tenant property at query time. That leaks risk if filters are wrong, forces every search to navigate a graph sized for the whole SaaS base, and makes “delete this customer for compliance” a slow, noisy tombstone storm across a shared index. Creating one collection per tenant avoids leakage but explodes schema management, connection overhead, and operational limits when you reach thousands of definitions. True multi-tenancy needs isolation strong enough for privacy and deletes, routing cheap enough that naming a tenant is not a full-cluster scan, and resource controls so idle tenants do not pin hot RAM forever.

The workable pattern is partition-by-tenant at the storage unit that owns the vector index.

How does shard-per-tenant isolation work?

Each tenant maps to its own shard: a self-contained bundle of object store, inverted indexes, and vector index. Queries and writes carry a tenant key so the engine opens only that shard — search latency looks like a single-tenant cluster of that tenant’s size, not the sum of all tenants. Deletes remove the shard (or its files) wholesale, which is far safer for regulatory wipe-out than hoping a filter matched every row. Large and small tenants coexist: a dynamic index can keep tiny tenants on a flat index and promote heavy ones to HNSW when they cross a threshold. Nodes still share CPU and memory, so a hot tenant can contend for machine resources — isolation is strong at the data layer, not a full noisy-neighbor firewall unless you add rate limits and placement policy.

Scale only stays affordable if cold tenants leave the hot path.

How do tenant activity states save cost?

Not every customer is online every hour. Activity states move a tenant between hot/warm local resources and colder tiers: active tenants serve reads and writes; inactive tenants sit on local disk without query access until reactivated; offloaded tenants move the whole shard to cheap remote storage until onloaded again. Lazy shard and segment loading avoid mapping every tenant into memory at process start. Auto-activation can wake a tenant on first access; deactivation and offload are typically explicit or scheduled by your app so you reclaim resources on purpose. State changes are eventually consistent across a cluster, so brief windows after offload or reactivate are expected. The payoff is paying RAM for the working set of active tenants, not for the long tail of trial signups that never returned.

Weaviate’s native multi-tenancy is built around exactly that shard-and-state model.

How does Weaviate implement multi-tenancy?

Enable multi-tenancy on a collection at creation time; every tenant then owns a dedicated lightweight shard with its own vector index. Tens of thousands of active shards per node are in scope, so a modest cluster can host on the order of a million concurrently active tenants. A tenant controller and optional auto-creation/activation knobs manage lifecycle. Within a shard, bucketed stores keep vectors, inverted indexes, and metadata separable, with per-bucket WALs for durable ingest. Prefer multi-tenancy over one-collection-per-customer when all tenants share the same schema; prefer separate collections when schemas truly diverge. Application-level authorization must still enforce that callers only pass tenant names they own — the database isolates storage, your API isolates identity.

Choosing the right isolation story is an architecture decision, not a checkbox.

When should you use multi-tenancy versus alternatives?

Use it for SaaS and multi-workspace products with one schema and many isolated corpora, especially when tenant count dwarfs objects per tenant. Use a single shared collection with filters only for soft partitioning inside one trust boundary. Use separate clusters when regulatory or noisy-neighbor requirements demand hard infrastructure isolation. Plan deactivate/offload jobs for dormant tenants, monitor active-shard counts and memory, and size for peak concurrent active tenants rather than total registered tenants. Test tenant delete end-to-end so compliance wipe-out is a practiced path, not a theory.

Multi-tenancy turns one vector database into many isolated search worlds with shared ops — shard-per-tenant plus activity states are what make millions of customers affordable. Next, read “What is resource governance?” for how clusters share CPU and memory fairly across those tenants, then “What is query-planner integration?” if you want how requests are steered to the right tenant shard without scanning everyone else.