Retrieval-augmented generation — grounded, fast, and 10x cheaper.
ManyVector stores your document embeddings in your own object store and retrieves the most semantically relevant chunks at query time. No in-memory database, no per-GB premium. Ground your LLM responses in private knowledge at object-storage prices.
The problem
Traditional vector databases are expensive at RAG scale.
- In-memory indexes charge you for idle RAM, even when not querying
- Per-GB premiums add up quickly as your corpus grows into the billions
- Separate search clusters mean separate ops burden and cost
- Re-indexing for a new embedding model requires full data duplication
How ManyVector solves it
Object storage is the RAG database.
- Your embeddings live in your S3, GCS, or R2 bucket — no per-GB markup
- Cold namespaces cost fractions of a cent per GB, not RAM prices
- Hybrid vector + full-text search in one API call for higher recall RAG
- Namespace branching lets you A/B test embedding models in production
A complete RAG pipeline in four steps.
01
Chunk & embed
Split documents into chunks. Run each through your embedding model (OpenAI, Cohere, local).
02
Upsert to ManyVector
Store the embedding + chunk text + metadata in your namespace. ManyVector writes to your bucket.
03
Query at runtime
Embed the user query. Run hybrid search to retrieve the top-k most relevant chunks.
04
Augment & generate
Inject retrieved chunks into the LLM prompt context. Get grounded, accurate responses.
Production RAG at object-storage prices.
10×
cheaper than in-memory
<15ms
retrieval p50
5
retrieval modes
Any
LLM or embedding model
Common questions
Which embedding models work with ManyVector for RAG?
Any model — OpenAI, Cohere, Anthropic, HuggingFace local, or custom. ManyVector is embedding-model agnostic; you bring the vectors.
How do I handle document updates without full re-indexing?
Upsert the updated chunks with the same IDs. ManyVector updates the index in place — no full re-index required.
Can I use hybrid and vector-only retrieval for different query types?
Yes. Pass search_mode="hybrid" or search_mode="vector" per query. Switch per request based on query characteristics.
What chunk size works best for RAG with ManyVector?
256-512 tokens per chunk is a common starting point. ManyVector stores chunk text as a metadata attribute alongside the embedding, so no separate document store is needed.