turbopuffer
A serverless vector and full-text search database built on object storage (S3/GCS/Azure) — usage-based pricing, hybrid search, and low cost per GB at scale.
turbopuffer is a serverless vector and full-text search database built from first principles on object storage (S3, GCS, Azure Blob). Vectors and BM25 indexes live durably in cheap object storage and are cached on NVMe/RAM only when queried, so storage cost stays low at very large scale while hot data still serves fast. Pricing is usage-based across storage, writes, and queries.
turbopuffer is a serverless vector and full-text search database built from first principles on object storage (S3, Google Cloud Storage, or Azure Blob). Instead of keeping every vector in RAM, it stores your vectors, BM25 indexes, and metadata durably in cheap object storage and pulls data into an NVMe SSD and memory cache only when it's queried. The result is that storage cost stays low even at very large scale, while frequently accessed ("warm") data still serves with low latency.
It's aimed at teams that want low-cost vector search at scale — large RAG corpora, product search, and recommendation systems — especially when data outgrows a RAM-first database's price tag. The core tradeoff is latency: warm queries are fast, but the first ("cold") read of a namespace pays an object-storage round-trip. In a RAG or AI workflow, turbopuffer is the retrieval layer: you embed documents, upsert them, and query by vector and/or keyword to fetch context before generation.
Highlights
- Object-storage-backed — vectors and indexes live durably in S3/GCS/Azure Blob, so storage cost per GB is low and you don't pay to keep everything in RAM.
- Vector + full-text (hybrid) search — combine dense vector search with BM25 keyword search in one engine to improve recall over either alone.
- Usage-based pricing — storage, writes, and queries are billed separately, which keeps mostly-cold datasets cheap; positioned as roughly 10x cheaper than RAM-first systems at scale.
- Namespaces for multi-tenancy — partition data into many independent namespaces, a natural fit for per-customer or per-tenant isolation at scale.
In an AI-assisted workflow
Use turbopuffer as the retrieval store behind your generation step: write your embedded chunks into a namespace, then query by vector (optionally with a keyword/BM25 component and metadata filters) to pull context.
// Upsert embedded chunks into a per-tenant namespace
await ns.write({
upsert_rows: [
{ id: "doc-1", vector: embed(text), content: text, product: "billing" },
],
});
// Query by vector, then over-retrieve and rerank downstream
const results = await ns.query({
rank_by: ["vector", "ANN", embed("How do I rotate API keys?")],
filters: ["product", "Eq", "billing"],
top_k: 20,
});Compare it against other engines in Best Vector Database (2026).
TIP
turbopuffer shines when you have many namespaces or tenants and care about cost-per-GB more than absolute lowest latency. Keep in mind that cold reads from object storage carry a latency penalty (a cold namespace pays an object-storage round-trip before the NVMe/RAM cache warms up), so size your latency budget around warm-vs-cold access patterns and verify current numbers on the official site.
Good to know
turbopuffer is a proprietary, usage-based SaaS — there's no public source and no perpetual free tier, with plans carrying minimum monthly commitments and higher tiers adding SSO, HIPAA BAA, BYOC, and private networking. Rates and tiers change, so confirm current storage/write/query pricing and any trial credits on the official pricing page before committing. For how object-storage-backed retrieval behaves as a corpus grows, see Vector Search at Scale.
Frequently asked questions
- What is turbopuffer?
- turbopuffer is a serverless vector and full-text search database built from first principles on object storage (S3, GCS, or Azure Blob). Your vectors and BM25 indexes are stored durably and cheaply in object storage, and pulled into an NVMe SSD and RAM cache only when queried — so storage stays inexpensive at very large scale while frequently accessed (warm) data still serves with low latency. It supports vector search, full-text/keyword search, and hybrid search, with namespaces for multi-tenancy.
- Is turbopuffer free, and how is it priced?
- turbopuffer is a proprietary, usage-based SaaS — you pay separately for storage, writes, and queries, which it positions as roughly 10x cheaper than RAM-first vector databases at scale. There is no perpetual free tier; plans carry minimum monthly commitments (a low-cost entry tier up through Scale and Enterprise tiers that add SSO, HIPAA BAA, BYOC, and private networking). Confirm current rates, tiers, and any trial credits on the official pricing page before you commit.
- How does turbopuffer compare to Pinecone?
- Both are managed, serverless vector search services, but the architectures differ. turbopuffer keeps data in object storage and caches hot data on NVMe/RAM, which makes cost-per-GB very low for large or mostly-cold corpora and many namespaces, at the cost of higher latency on cold reads. Pinecone is a more established managed service with its own serverless model. Choose turbopuffer when storage cost at scale and per-tenant isolation matter most; benchmark both on your own recall and latency targets.
Related
- Best Vector Database in 2026: pgvector vs Pinecone vs Qdrant vs Weaviate vs Milvus vs Chroma vs LanceDBA decision guide to vector databases — embedded, server, or managed; whether you already run Postgres; and which fits your scale, filtering, and RAG needs.
- Vector Search at Scale: ANN Indexes, Quantization & ShardingHow to run vector search over millions to billions of vectors without blowing latency, memory, or cost — index families, quantization, filtering, and sharding.
- pgvector vs Pinecone: Do You Need a Vector Database? (2026)pgvector vs Pinecone compared — vector search inside the Postgres you already run vs a dedicated managed service. Scale thresholds, ops, and the honest default.
- How Embeddings Work: Vectors, Similarity, and Choosing a ModelWhat an embedding actually is, how similarity is measured, how the models are trained, and the practical rules for using embeddings well in search and RAG.
- Hybrid Search & Reranking: From Top-50 Recall to Top-5 PrecisionHow production RAG combines dense and sparse search, fuses with RRF, and reranks — turning a wide candidate set into the few passages that actually answer.