What is Namespace
Namespace - An isolated vector space with its own schema, indexes and access boundary
A namespace is the isolation boundary in a vector database. Everything inside one namespace shares a vector dimensionality, a distance metric, a payload schema and a set of indexes, and nothing crosses between namespaces: a search issued against one never returns a document from another. It is the unit teams reach for when one deployment has to serve several tenants, several embedding models, or several environments without any of them seeing each other's data.
How It Works
Every write and every query carries a namespace, usually as a header or a path segment, and the store routes on it before it does anything else. Because the namespace fixes the vector dimensionality and the distance metric, the index inside it can be built for exactly one shape rather than for a union of shapes, which is what makes the isolation cheap rather than merely tidy. Two namespaces on the same cluster can hold vectors of different dimensions from different models, and neither has to know the other exists.
Technical Details
A namespace typically owns its own payload indexes, so a field you can filter on in one is not automatically filterable in another. It is also the usual boundary for quotas, retention and access control, which means it tends to be the object an API key is scoped to. In systems that keep data in object storage, the namespace is often the prefix under which that tenant's objects live, so the isolation is physical as well as logical. Changing the embedding model for a namespace is not an in-place edit: because the dimensionality is fixed at the namespace, a model migration means a new namespace and a re-index rather than an alter-table.
Common Pitfalls
- Using one namespace per customer when you have hundreds of thousands of small customers, where the per-namespace overhead dominates and a tenant field with a filter would serve better
- Assuming a payload index created in one namespace applies in another
- Discovering at migration time that the dimensionality is fixed per namespace, so a new embedding model needs a new namespace rather than a schema change
- Treating the namespace as the only isolation you need, when queries still have to be scoped by entitlement inside it
- Letting an API key span namespaces it does not need, which quietly removes the boundary you created the namespace for
Relevance to Multimodal Systems
Multimodal corpora make namespaces load-bearing rather than optional, because one product surface often runs several embedding models at once: a text encoder, an image encoder, and something for audio or video, each with its own dimensionality. Those cannot share an index, so they are naturally separate namespaces that a retrieval pipeline queries and then fuses. Namespaces are also how the same platform serves a media customer's licensed footage and their user-generated content without either turning up in the other's search results. In Mixpeek a namespace is one of the core primitives alongside buckets, collections, extractors, retrievers, taxonomies and clusters; see namespaces for the capability, the namespaces documentation for the API, and multi-tenant vector search for how to choose between namespace-per-tenant and a tenant filter.
Put multimodal search to work
Connect a bucket and Mixpeek runs the whole multimodal search pipeline for you: extraction, indexing, and search over your own objects. No models to wire up, nothing to host.
Start with ManagedAlready have vectors?
Keep your embeddings on your own cloud and run dense, sparse, and BM25 search directly on object storage. From $25/mo.
Start with MVS