Skip to main content
Bring your own embeddings, upsert them directly, and query with dense, sparse, BM25, or hybrid search. No collections or extractors required.

Create a vector namespace

Upsert your own embeddings and run a search in minutes, with no extractors or schema to declare. Creating a namespace needs a plan; see Billing for what each one covers.

Quickstart

1

Create a namespace

No schema needed. MVS infers vector dimensions on first write.
Pick a vector name of your own, like my_text_v1. A few short generic names (text_embedding among them) collide with legacy pre-namespace keys in the store, and a namespace that uses one accepts your writes with a 200 and then refuses every search with a 409 (a cross-namespace index refusal). Prefixing with your project or model version avoids it.
You can optionally pre-declare vector configs if you want to set a specific distance metric:
2

Upsert documents with your vectors

3

Create a retriever (one-time)

Querying is unified on retrievers: one query concept whether you bring your own vectors or promote to managed embedding. Create a retriever once; for a standalone namespace it takes the query vector you computed (input_mode: vector). All requests are scoped to the namespace via the X-Namespace header.
4

Execute the retriever

Run the retriever with your query embedding. Each hit exposes document_id and payload fields.

Architecture

Standalone vector store architecture: your pipeline feeds vectors into Mixpeek's sharded storage with dense, BM25, and payload indexes

Scaling

The index auto-partitions as you grow. There’s no capacity planning, resharding, or replica provisioning on your side, and no per-vector or per-namespace caps. The same namespace serves thousands or hundreds of millions of vectors. At large scale (10M–100M+ vectors), two things matter:
  • Tiering. Hot (in-memory) vectors serve at ~10ms; cold (object-storage) vectors serve at ~100ms via brute-force scan. The vector store keeps your actively-queried set resident automatically, so there’s no manual tier management on your side.
  • Shard visibility. The shards.hot / shards.cold counts in namespace usage metrics show how the index has partitioned. Dedicated/enterprise deployments can tune shard and index parameters (see Single-Tenant).
Need concrete latency/recall targets for a specific corpus size and query rate? Talk to engineers. Sizing depends on dimensions, filter selectivity, and your hot/cold split.

Standalone vs Managed

Every namespace runs in one of two modes. Start standalone and promote when you’re ready, with no reindexing.
Start standalone if you already have embeddings. Promotion is additive: all existing data is preserved.

Features

All features work identically in standalone and managed modes.

Billing

MVS pricing is pure usage-based, with no per-vector caps and no namespace limits. Tiers gate support level, not features. Tier minimums and what each one includes live on one page: Billing. All search features (dense, sparse, BM25, hybrid, adaptive indexes) are available on every tier. See the pricing calculator for cost estimates at scale. Track usage programmatically with the vector-backend usage endpoint (GET /v1/organizations/billing/usage/vector-backend) or view it in the Studio dashboard under Billing.

Next Steps

Namespaces

Vector indexes, metrics, BM25

Documents & Search

Upsert, query, manage

Promote

Standalone → managed

Ready to go beyond BYO vectors? Promote your standalone namespace to managed mode and add automatic embedding, file processing pipelines, and enrichment without reindexing. Your retrievers keep working unchanged: after promotion, the same retriever can auto-embed raw text instead of taking a pre-computed vector. See the migration guide for details. Learn how to promote →