Vector & retrieval
turbopuffer
Vector and full-text search built on object storage, priced for large, comparatively cold datasets.
- Category
- Vector & retrieval
- Pricing
- Usage-based
- Runs
- Hosted
- Interface
- API
- Source
- Proprietary
What turbopuffer is
turbopuffer stores indexes on object storage with caching in front, rather than keeping everything resident in memory. That inverts the usual cost model: you pay close to what you query instead of paying to hold the whole corpus hot, which is a large difference on datasets that are big but rarely fully read.
Best for
Large corpora where only a fraction is queried regularly, and per-tenant indexes that are mostly idle.
Consider something else if
Object-storage-backed reads mean cold queries are slower than a memory-resident index; check the tail latency you need.
turbopuffer alternatives
The closest options in vector & retrieval, on the axes that actually separate them.
| Tool | Best for | Pricing | Runs |
|---|---|---|---|
| turbopuffer | Large corpora where only a fraction is queried regularly, and per-tenant indexes that are mostly idle. | Usage-based | Hosted |
| Pinecone | Teams who want retrieval to be somebody else's operational problem and are content to pay for that. | Usage-based | Hosted |
| Qdrantopen source | Filter-heavy retrieval — multi-tenant, permissioned, or time-scoped — where naive filtering degrades results. | Open source | Hosted or self-hosted |
| pgvectoropen source | Anyone already running Postgres with up to a few million vectors, which is a larger share of real applications than the category implies. | Open source | Self-hosted |
| Weaviateopen source | Corpora containing identifiers, product codes, or proper nouns, where pure vector search visibly misses. | Open source | Hosted or self-hosted |
| Chromaopen source | Prototyping retrieval, notebooks, and small applications where a service is overkill. | Open source | Hosted or self-hosted |
Choosing within vector & retrieval
Whether Postgres is already enough
Ask this first and take the answer seriously. At small and medium scale the extension removes a service, a sync problem, and a second consistency model, at very little cost in capability.
Metadata filtering
Real queries are almost never pure similarity — they are similarity within a tenant, a date range, or a permission scope. How well a store combines filters with vector search is the difference that shows up in production.
Questions
What is turbopuffer?
turbopuffer stores indexes on object storage with caching in front, rather than keeping everything resident in memory. That inverts the usual cost model: you pay close to what you query instead of paying to hold the whole corpus hot, which is a large difference on datasets that are big but rarely fully read. It is a commercial product and hosted.
What are the alternatives to turbopuffer?
The closest alternatives are Pinecone, Qdrant, pgvector, Weaviate, Chroma. They sit in the same category — vector & retrieval — and differ mainly on hosting model, pricing shape, and how much they abstract away.
Is turbopuffer the right choice?
Large corpora where only a fraction is queried regularly, and per-tenant indexes that are mostly idle. The main caveat: Object-storage-backed reads mean cold queries are slower than a memory-resident index; check the tail latency you need.
Whatever you build on, the model is the line item that scales. See what each one costs per million tokens, or price your own workload.