Namespace (Vector DB) — AI Glossary

Reference details

Related terms

• Metadata Filtering
• Approximate Nearest Neighbor (ANN)
• Dense Retrieval

How it works

1. A namespace is a logical partition inside one index: vectors are written with a partition key, and a query names the partition it searches.
2. Isolation is enforced at query time by the partition, not by a post-filter on results. This is the security-relevant difference — a filtered search can return a leaked neighbour if the filter is applied after scoring, while a partitioned search never considers the other partition's vectors.
3. Approximate-nearest-neighbour structures are built per partition, so recall and latency depend on the partition's own size rather than the whole index's.
4. That makes per-partition cost sublinear in a useful way for large tenants and wasteful for small ones: a partition holding fifty vectors still carries index overhead, so thousands of tiny partitions cost more than one filtered index.
5. Cross-partition search generally requires querying each and merging, so a question spanning tenants becomes N queries and a client-side merge rather than one search.
6. Deletion is where partitions pay off operationally: removing a tenant is dropping a partition, which is a single operation rather than a filtered delete across a large index.

Example: When a partition beats a metadata filter, and when it loses

100 tenants with 10,000 vectors each — 1,000,000 in total. In one index with a tenant filter, an approximate search traverses a graph built over all 1,000,000 vectors and then restricts to the matching tenant; if the filter is applied after retrieving the top 100 candidates and a tenant holds 1% of the index, roughly 100 x 0.01 = 1 of those candidates belongs to the right tenant, so recall collapses and the engine has to over-fetch heavily to compensate. Partitioned, each search traverses a graph of 10,000 vectors and every candidate is valid: recall is what the index structure gives at that size, and latency is lower because the graph is a hundredth the size. Now change the distribution to 100,000 tenants with 10 vectors each. Each partition holds 10 vectors, where an ANN structure does nothing a brute-force scan would not do faster, and the per-partition overhead is paid 100,000 times. There the filtered single index is correct. The crossover is about whether a partition is large enough for its own index to be worth building, which in practice means thousands of vectors rather than tens.

Commonly confused with

A namespace is not a metadata filter, although both narrow a search. A filter is a predicate evaluated against candidates, so whether it is applied before, during or after scoring is an engine implementation detail that determines both recall and whether cross-tenant leakage is possible. A namespace is a separate index: the other tenants' vectors are not in the structure being searched. For multi-tenant isolation that distinction is the difference between a guarantee and a configuration you have to verify, which is why per-user isolation belongs in partitions and per-document-type narrowing belongs in filters.

When to use it

Reach for it when:

• Multi-tenant applications where cross-tenant leakage is unacceptable and isolation needs to be structural.
• Tenants large enough to justify their own index — thousands of vectors rather than tens.
• Frequent whole-tenant deletion, where dropping a partition replaces a large filtered delete.
• Comparing embedding models side by side, where two partitions hold the same corpus under different encoders.

Reach for something else when:

• Very many very small partitions, where per-partition overhead dominates and a filtered index is cheaper and faster.
• Queries that must span partitions, which become N searches plus a merge rather than one search.
• Narrowing by attributes rather than by tenant — document type, date, language — which is what filters are for.
• As the only tenancy control, since the application must still be prevented from naming another tenant's partition.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Namespace (Vector DB) — AI Glossary.

• Browse models
• Review providers
• Inspect benchmarks
• Explore workflows
• Learn AI concepts
• Read decision guides
• Review trust and methodology
• Start a decision path