How do you decide between Weaviate tenants, one collection per customer, and a tenant property?

## Three shapes, one decision Every multi-customer deployment on Weaviate faces the same fork, and it is the kind of question a lead is expected to own because the choice is effectively permanent — whether a collection is multi-tenant is fixed at creation. ## Built-in tenants You opt in at creation with `multi_tenancy_config=Configure.multi_tenancy(enabled=True)`, optionally with automatic tenant creation on first write and automatic activation on access. Tenants are then managed through the collection handle — create, get, update and remove — and every data or query call goes through `collection.with_tenant("acme")`. A call that omits the tenant on a multi-tenant collection is an error, which is the point: isolation is enforced by the engine, not by remembering a filter. What you get: - **Physical separation.** Each tenant has its own shard and its own vector index. One customer's bulk import does not reshape another's graph, and their vectors never sit in the same search space. - **Cheap deletion.** Removing a tenant drops its shard. Compare that with deleting a million objects by filter, which is a slow, compaction-heavy operation — and matters for data-deletion obligations. - **A lifecycle.** Tenants can be active, inactive, or offloaded to cold storage. Inactive tenants release memory while keeping their data; activation happens on demand. In a product where a minority of customers are active on any day, this is the difference between paying for all of them and paying for the working set. - **Sensible index economics.** Because each tenant is a separate small index, a flat or dynamic vector index usually fits better than a full HNSW graph per tenant — the two decisions are made together. The costs: per-tenant shard metadata is real, so tens of thousands of tenants need attention to node memory and activation policy; cross-tenant queries are not a thing, so any global analytics needs a different path; and references cannot span tenants. ## A collection per customer This looks like stronger isolation and is usually worse. Collections are cluster-level schema objects, coordinated across nodes, so thousands of them inflate the schema and its coordination overhead in a way the tenant model is specifically designed to avoid. Worse, every schema change becomes an N-way migration — add a property and you apply it a thousand times, with partial-failure states. It is a defensible choice for a handful of very large, genuinely different customers, especially when their schemas actually differ or their data must live in separate deployments for compliance. It is not a general SaaS design. ## A tenant property and a filter One collection, a `tenant_id` property, and every query filtered by it. It is the simplest thing that works and it is right for some cases — few customers, small data, or a product where cross-customer search is a feature rather than a breach. Its weaknesses are systematic: - **No enforced isolation.** One forgotten filter is a data leak. The safeguard is code discipline, which fails eventually. - **Shared index.** All customers occupy one vector index, so a filtered search still works within a structure shaped by everyone's data, and a large customer degrades a small one's latency. - **Expensive offboarding.** Deleting a customer is a bulk delete plus cleanup, not a metadata operation. - **No per-customer economics.** You cannot deactivate an idle customer or offload them; everything is resident all the time. ## How to choose Ask how many customers, how skewed their sizes are, whether isolation is a compliance obligation or a preference, and how often customers are offboarded. Many customers plus a hard isolation requirement plus routine offboarding points squarely at built-in tenants. A handful of customers with modest data and no isolation obligation makes the filter approach honest and simple. Genuinely divergent schemas or separate compliance domains justify separate collections — or separate clusters. Then ask about the shape of the tail. If 90% of tenants are tiny and 10% are large, the tenant model plus a dynamic vector index and an aggressive deactivation policy gives you both economics and headroom. ## The trap to name explicitly Multi-tenancy cannot be switched on later. A team that ships with a `tenant_id` filter and plans to "migrate to tenants when we grow" is planning a full re-import of every customer's data under a new collection, with a cutover. Say that out loud in the design review, because that is the moment the decision is cheap.