Mapping Multi-Tenancy Across Vector Databases

And, knowing Daniel, he doesn't want the feature-matrix version. He wants the thing he can carry in his head to whichever database lands on his desk next year.

Start with the mechanism, because everything else follows from it. An approximate nearest neighbor index doesn't see tenant boundaries. It walks a graph or probes a set of lists, hands the executor whatever candidates are closest, and row visibility gets reconciled afterward. That's true of every vector database, from the managed ones down to pgvector sitting in a Postgres schema. The index is a neighborhood machine. It has no idea who owns a vector.

That's the whole ladder, compressed. If the boundary is inside the index, or the shared index doesn't exist, then isolation is structural. If the boundary is outside the index, you're paying for it in recall, latency, and money, every single query.

Five, hardest to softest. Separate instance, own compute, own failure domain, nothing shared. Then separate index or collection, a distinct physical object with its own schema and its own graph. Then partition or namespace, a physically separated slice inside a shared object, addressed by name when you query. Then partition key, which is a routing key that maps tenants onto a fixed number of physical partitions, several tenants to a partition. And at the bottom, metadata filter on a shared index. One graph, a tenant_id field, a where clause.

Nicely put, even. And the levels aren't cosmetic. Levels one through three change what the index physically contains. Levels four and five keep one graph for everyone and reconcile visibility after the fact. That reconciliation is where the interesting problems live, and it's also where the money goes.

Pinecone namespaces are level three, cleanly. A namespace is a physically separated slice inside a serverless index, and you address it by name at query time. Their docs are unusually direct about it. They call namespaces the most efficient way to do multitenancy, and they say each namespace is stored separately, so you get physical isolation between tenants, which reduces the risk of application bugs searching the wrong tenant's data. Limits run from a hundred namespaces on the Starter plan to a million on Enterprise.

It does mean the limit is a business line, not an architecture line. The architecture goes further, they say they'll accommodate more for specific cases. What I love about Pinecone's docs is they publish the cost arithmetic. Search cost is based on namespace size, one read unit per gigabyte. A hundred tenants of one gig each, searching one tenant's namespace costs you one RU. Put all hundred tenants in a single hundred-gigabyte namespace and use metadata filtering, the same search costs a hundred RUs, because it scans everything regardless of the filter.

That's the inversion nobody expects. Everyone assumes isolation is the expensive, luxury option and sharing is the lean startup move. In vector search it's backwards, because cost tracks data scanned. Isolating the tenant shrinks what you scan.

They call it, quote, a common anti-pattern. Storing all data in a single namespace and using metadata filters to scope searches to specific users. Their objections are practical, not philosophical. Large in-filters balloon the network payload and latency, and each in or nin operator is capped at ten thousand values. Exceed it and the request just fails. Their guidance is to prefer namespaces unless you require querying across tenants.

Right, and it's a where clause you're maintaining by hand. One other Pinecone detail worth keeping, offboarding. Delete the namespace and the tenant is gone, and their word for it is that it's lightweight and almost instant. Compare that to the metadata model, where offboarding a tenant means listing every record by ID prefix and batch-deleting them. One of those operations you can run at two in the morning, and the other you schedule.

It's a shard per tenant. A shard is a self-contained storage and query unit, and in their native multi-tenancy every tenant's data lives in its own shard. Structurally, that's level three, same rung as Pinecone namespaces, different word. What Weaviate adds on top is the Tenant Controller, which I find elegant. Three states per tenant. ACTIVE, meaning it's using memory and compute. INACTIVE, resources freed but quickly accessible. OFFLOADED, pushed to cold storage like S3 until someone touches it again. And it can activate a tenant automatically the moment a search or update lands on it.

That's the bet, yes. Most tenants are dormant most of the time, and keeping them all warm in memory is the actual cost driver at scale. Weaviate claims over a million tenants per cluster on that basis. Which is a vendor claim with no benchmark attached, I'd hold it loosely. And their own docs carry the honest caveat. Tenants still share node resources, CPU, memory, I/O, network. A heavy enough workload on one tenant can still squeeze the node. Sharding isolates the data, not the machine.

One floor down and with a better thermostat. The other Weaviate piece is collection-level isolation, and it matters for a different reason. Every collection has its own vector space, meaning different collections can hold different embeddings of the same object. So if your tenants need different embedding models, or different dimensions, collection-per-tenant is the argument. Same logic shows up everywhere. Metadata filtering can't give a tenant its own dimensions, because the index dimensions are fixed for everyone inside it.

Milvus is the only vendor that publishes the ladder explicitly, which I appreciate, because you can map everyone else onto it. Database level, sixty-four tenants by default, fully separated data, which they call enterprise-grade isolation ideal for regulated environments. Full schema flexibility per tenant, role-based access control supported, hot and cold data handling supported. Collection level, up to sixty-five thousand collections by default, physically isolated from one another, medium schema flexibility. Partition level, a thousand and twenty-four partitions per collection, tenant data physically separated, cross-tenant queries supported, but RBAC is not supported at partition level. And then partition key level, which they call the most scalable approach, supporting millions of tenants.

Their own words are relatively weak data isolation, because multiple tenants can share a physical partition. The partition key routes tenants into sixteen physical partitions. Sixteen. So tenant number four thousand and tenant number nine hundred and one may be sitting in the same physical bucket, logically separated and not physically isolated.

And the gotcha buried in their docs is a nice one. They recommend a scalar index on the partition key field, because each physical partition holds multiple tenants, and Milvus evaluates the tenant filter against every entity in the searched partitions. Without the index, that's a full scan. So even the scalable rung quietly reintroduces the filtering problem, just one level shallower.

Clearest in the industry. Three rankings. Scalability, partition key beats partition beats collection beats database. Strong isolation, database and collection tie at the top, then partition, then partition key. Schema flexibility, database, then collection, then partition and partition key tied at the bottom. And the cross-tenant column, only partition and partition-key support it. Read that table and you realize the vocabulary differences between Pinecone and Weaviate and Milvus are almost decoration. Pinecone namespaces and Weaviate tenants are both level three. Milvus just spans levels two through four and labels each rung. Qdrant, which we're leaving for the other episode, sits on the same ladder with its own words.

Worth one line of cleanup. In the vector DB world, federation usually means querying across separate clusters. What we're talking about is isolation levels within one deployment. Cross-tenant search inside one system, which is different from federating systems.

Chroma gives you tenant, then database, then collection, a three-deep hierarchy. Tenant is the top-level account boundary, database is a project space inside the tenant, collection is the dataset inside that. On a single-node setup, all of it, tenancy, databases, collections, documents, sits in one SQLite file.

There really is. Their cookbook names four strategies, and I do admire the candor of the framing. User per doc, which is the metadata filter, level five. User per collection. User per database. User per tenant. And they label the whole thing, quote, a naive approach to multi-tenancy and probably not suited for production environments. Their own ladder, their own warning label.

They do, and they spell out why. User per doc is error-prone, messing up the filtering can leak data across users, and filtering gets slow as users and documents grow. User per collection is error-prone in a different direction, messing up the collection name can leak data. One typo swaps the rung you're standing on.

Back to Postgres primitives, which means three models, and I actually think this is the clearest teaching version of the whole ladder, because Postgres makes you build each rung by hand. Shared table plus RLS is level five. One document embeddings table, every tenant's rows, a tenant_id column, an RLS policy reading a session variable. Densest layout, cheapest to operate, one index, one vacuum target. And also, in the words of the pgvector guide I read, the model where the ANN-versus-visibility reconciliation problem is sharpest. The index is built over all tenants, so your query walks foreign rows before they're filtered out. You spend recall budget on candidates you're going to throw away.

The bouncer checks the list after everyone's already inside, which is worse. Schema-per-tenant is level two. Each tenant owns a schema with its own embeddings table and its own index, and isolation becomes a grant and search_path question rather than a per-row predicate. The index contains only that tenant's vectors, so recall isn't diluted. The cost is multiplicity. Hundreds of schemas means hundreds of indexes to build, tune, and vacuum, and every DDL migration fans out across all of them. Best for few large tenants with strict compliance separation. Partition-per-tenant is the middle ground, level three and four hybrid. Postgres prunes irrelevant partitions before RLS is even evaluated, and each partition carries its own ANN index, so scans stay tenant-local while DDL stays centralized. The guide's threshold is once any single tenant exceeds a few million rows, roughly five million, you move that way.

It is. Many small tenants, shared table. One whale tenant, partition-per-tenant. Few big regulated tenants, schema each.

The guide puts numbers on it, which almost nobody else does. With shared-table RLS you're post-filtering, so you over-fetch candidates and then discard the foreign ones. To recover the recall you lost, they suggest raising hnsw ef_search from its default of forty to somewhere between one hundred and two hundred. If you're on ivfflat, raise probes from the default of one to ten to forty. That's the closest thing in all this research to a quantified recall penalty for the metadata-filter approach, and it's Postgres-specific. Nobody has published the equivalent for the vector databases.

It's a recall subsidy. And the hardening list for shared-table RLS is its own education. A nullable tenant_id is a leak waiting to happen, so it's NOT NULL, full stop. Plain ENABLE row level security exempts the table owner, so you use FORCE. You split the USING clause for reads from the WITH CHECK for writes. You bind the tenant context with SET LOCAL, per transaction, never per pool, because a pool connection outlives the request and the setting can leak to the next borrower. And you pin row_security on, because a client can set it to off, and if the role has BYPASSRLS that disables policies entirely.

It's the line that separates people who've debugged a connection pool at three in the morning. There's a subtler leak in the same guide, too. Bad reconciliation doesn't always surface as the wrong document in the results. It can leak cluster density through the distance-score distribution, or through query timing. You can fingerprint which tenants exist from timing alone.

Mum, always a pleasure. The Toastmaster.

Where were we. Timing leaks, pgvector hardening.

And it comes down to a handful of questions, none of which is which vendor you like. First, tenant count, and before that, who the tenant even is. Pinecone has a case study with a company called Shortwave, and the detail that matters is that their tenant is the individual user, not the company. Strict separation between users. The moment your tenant unit is a human being rather than an organization, your cardinality explodes, and the isolation level follows from the cardinality, not from the database. A million-user product can't do schema-per-user. It probably can't even do namespace-per-user past a point, and then you're into Pinecone's mapping-table pattern, resolving the tenant to an index first, then querying the namespace inside it.

Corn, you'd be amazed how often that decision is made implicitly, by whoever wrote the first insert statement, and never revisited. Second question, compliance. Milvus says it plainly, choose database, collection, or partition-level if you have strict physical isolation requirements. pgvector, schema-per-tenant for strict compliance separation. Regulated customers, that's level two or above, non-negotiable. Third, schema heterogeneity. Different embedding models or different dimensions per tenant forces you to collection-level or higher. One shared index has one vector space, full stop. You cannot give tenant B different dimensions inside tenant A's index.

Cross-tenant search. The one product requirement that pulls you down the ladder instead of up it. Milvus is explicit, only partition-level and partition-key-level tenancy support cross-tenant queries. Pinecone says prefer namespaces unless you require the ability to query across tenants. If your product needs a superuser searching everyone's data, that single requirement can cost you two rungs of isolation.

Their federated search example is an internal knowledge-base chatbot federating a hundred and fifty different SaaS products, where an admin searches everything. Internal tooling, elevated user, all tenants belong to one organization anyway. That's the legitimate case, and notice it's not really multitenancy. It's one tenant with a hundred and fifty sources. When teams think they need cross-tenant search for end users, what they usually need is a shared collection everyone reads, plus per-tenant private ones.

That, and it composes cleanly. The remaining decision inputs are quieter. Tenant size skew, the pgvector five-million-rows threshold for partition-per-tenant. Cost model, the one RU versus a hundred RU arithmetic, where isolation is usually cheaper because you scan less. Offboarding, namespace deletion is instant, metadata tenancy means prefix listing and batch deletes. And hot/cold, which I think is the hidden operational axis of the whole topic. Weaviate's ACTIVE, INACTIVE, OFFLOADED controller and Milvus's per-tenant load and release are solving the identical problem. Most tenants are idle. Milvus's own table quietly notes that partition-key tenancy doesn't support hot and cold handling. Buried in a footnote, and it's the reason the most scalable rung costs more than it looks.

Four independent vendors, no coordination, all converging on don't do the cheap thing. When competitors agree, believe them.

It's cheap on day one and expensive forever, which is the standard shape of a bad architecture decision. What's your instinct, though? You've leaned pro-isolation this whole episode, and you usually defend the boring shared option on the grounds that it's one thing to operate.

A typo in a namespace returns nothing. A typo in a metadata filter returns someone else's customer.

I imagine he didn't.

He's not entirely right either. A schema doesn't come with its own ANN graph per tenant.

He gets the wrong customer's documents, and no error.

The sticky note stays.

And Chroma's production story is thinner than it looks. Their official multi-tenancy guide page doesn't resolve, and the substantive guidance lives in the community cookbook, the one that disclaims production suitability. So the honest closing image is the ladder itself. Five rungs, one question at each. Does the index know the tenant?

They haven't in Postgres's case for decades. The one thing I'd push back on you about, before we close it. You said level three is the default. I'd say the default is actually level three or level two depending on tenant count, and the real default question is who is the tenant, which most teams answer by accident.

And it's wrong in both directions at once. It's not cheap, the hundred-RU example says it can be a hundred times more expensive, and it's not safe, it's the only rung where a missing filter is a data breach instead of an empty result. Every vendor in this space has effectively said so in their own documentation.

Thanks as always to Hilbert Flumingtop at the desk, producing the show out of whatever the sticky note says.

See you tomorrow, Corn.