Turbopuffer for RAG

turbopuffer is a managed vector and full-text search database built on object storage with a memory/SSD cache in front. Its appeal is cost when most namespaces stay cold; its tax is higher latency until a namespace is warm. This page states both.

What is turbopuffer?

turbopuffer is a managed vector and full-text search database that keeps durable data on object storage and serves active data from memory and SSD cache. The July 2026 homepage describes vector search, BM25 full-text search, hybrid search, and metadata filtering in one product, marketed as roughly 10× cheaper than traditional always-hot vector databases for the workloads it targets.

It is not an open-source engine you self-host. Braintrust’s 2026 vector-database survey and Modern Data Tools’ 2026 review both classify turbopuffer as managed-only. The homepage also publishes production-scale claims — 4T+ documents, 10M+ writes/s, and 25k+ queries/s seen in production — which are vendor figures, not an independent benchmark on your corpus. Category background sits at vector databases.

How does turbopuffer’s object-storage architecture work?

Durable vectors live on cheap object storage; active namespaces hydrate into SSD and then RAM — the architecture Simon (turbopuffer’s CEO) described in Jason Liu’s September 2025 session as a “pufferfish” that inflates when queried and deflates when idle. The homepage diagram is the same story: client → memory/SSD cache → object storage (S3-class).

The index design matches that storage physics. turbopuffer’s vector docs say vectors are incrementally indexed in an SPFresh index; the Jason Liu write-up contrasts clustered indexes (few large fetches) with graph indexes such as HNSW that need many small round trips — a bad fit for object storage. Writes go to object storage first, which is why write latency is part of the trade, not an accident. The HNSW mechanism itself is covered at HNSW; the symptom of slow first queries belongs with RAG latency failures.

How does turbopuffer work for RAG?

For RAG you upsert documents with vectors and attributes into a namespace, then run an approximate nearest-neighbour query with optional filters before generation. The vector-search guide (July 2026) says writes appear in search results immediately, the index is automatically tuned for roughly 90–100% recall@10, and a recall endpoint exists so you can measure it yourself. Full-text (BM25) and hybrid guides sit beside the vector guide for keyword-sensitive RAG.

Namespaces are the multi-tenant shape. The Jason Liu session describes Cursor mapping codebases to namespaces and warming cache when a project opens, and Notion running large vector counts across millions of namespaces where only a subset is active — exactly the cold-heavy pattern object storage is built for. Filter design belongs at metadata filtering; tenant isolation patterns at multi-tenancy; hybrid score fusion at hybrid search; wiring code at how to build a RAG pipeline.

What are turbopuffer’s capabilities and limits, side by side?

turbopuffer is easiest to judge when the cost win and the cold-start tax sit in the same table.

That warm/cold gap is the architecture, not a misconfiguration. If every query must be hot on first touch, object-storage-first search is the wrong bet.

How much does turbopuffer cost?

As of the July 2026 pricing-page capture, turbopuffer sells plan minima rather than a free production tier: Launch at $16/month minimum usage, Scale at $256/month, and Enterprise from ≥$4,096/month with a published 99.95% uptime SLA. Usage for storage, writes, and queries sits on top of those minima — use the on-page calculator for a workload shape.

The economic claim on the homepage is order-of-magnitude cheaper storage versus always-RAM vector databases; the Jason Liu session relays customer anecdotes of roughly 95% savings after migration. Those are vendor and customer claims, not a number this site measured. Prefer the official pricing page over third-party reviews when figures disagree (at least one 2026 review still listed a higher Launch minimum than the $16 figure on turbopuffer.com). Cost still belongs in the broader vector-database decision once you know how cold your namespaces really are.

Turbopuffer vs Weaviate: which trade-off matters for RAG?

The choice is usually object-storage cost versus portable control. turbopuffer optimises for managed search where most data stays cold between queries. Weaviate optimises for an open-source vector database you can self-host, with native hybrid search and modules outside a single managed control plane.

Pick turbopuffer when storage cost across many idle namespaces dominates the bill and you can tolerate cold-start latency or cache warming. Pick Weaviate when self-hosting, local parity, or open-source deployment control is the hard requirement. Pinecone remains the comparison point for teams that want managed search with a more always-hot latency profile and a different cost curve. The scored multi-database verdict belongs at which vector database should you use for RAG.