> turbopuffer reviewed: object storage as the source of truth, SPFresh and RaBitQ, hybrid search, per-GB pricing against Pinecone, and when it wins.
>
> Web page: https://balazscsorba.com/blog/turbopuffer · Language: English · Also available in: [Deutsch](https://balazscsorba.com/de/blog/turbopuffer.md) · [Magyar](https://balazscsorba.com/hu/blog/turbopuffer.md)
> Author: Balázs Csorba · Published: 2026-09-29 · Updated: 2026-10-01 · Keywords: turbopuffer, turbopuffer pricing, vector search on object storage, serverless vector database, turbopuffer vs pinecone, turbopuffer namespaces, spfresh vector index, hybrid search bm25 vector, per-query vector database pricing, object storage vector database

[Blog](https://balazscsorba.com/blog)/Retrieval & search

# turbopuffer review: vector search built on object storage, and what it costs per query

turbopuffer reviewed: object storage as the source of truth, SPFresh and RaBitQ, hybrid search, per-GB pricing against Pinecone, and when it wins.

[Balázs Csorba](https://balazscsorba.com/about)·September 29, 2026·updated October 1, 2026·8 min read

-   turbopuffer
-   Vector database
-   Object storage
-   Pricing
-   Hybrid search

![A large storage bucket below and a small cache tray above that pulls up a few cards.](https://balazscsorba.com/images/blog/turbopuffer/cover.webp?v=e4fb597603)

## Key takeaways

-   turbopuffer keeps every namespace as a prefix on object storage and serves queries from stateless nodes with NVMe and memory caches, so idle data costs storage prices.
-   Vendor-published latency: about 10 ms p90 for a warm 1M-vector namespace and about 444 ms p90 cold, with cold queries capped at about three object-storage roundtrips.
-   The ANN v3 index combines SPFresh-style hierarchical clustering with RaBitQ binary quantization and targets 100 billion vectors in one index.
-   Billing is per GB stored, written, scanned and returned rather than per operation, which favours many small tenants and mostly idle corpora; as of October 2026 the minimums are $16 and $256 a month.
-   All performance and cost numbers here are vendor-sourced; run your own namespace size, filter mix and cold-query rate through both pricing models before migrating.

On this page

1.  [What it is](https://balazscsorba.com/#what-it-is)
2.  [How it works](https://balazscsorba.com/#how-it-works)
3.  [Getting started](https://balazscsorba.com/#getting-started)
4.  [Pricing, and how it compares with Pinecone](https://balazscsorba.com/#pricing)
5.  [Where it breaks](https://balazscsorba.com/#where-it-breaks)
6.  [Alternatives](https://balazscsorba.com/#alternatives)
7.  [Verdict](https://balazscsorba.com/#verdict)
8.  [Sources](https://balazscsorba.com/#sources)

Listen to this article

0:000:00

**turbopuffer** is a managed search engine for vectors and full text whose source of truth is object storage, not a cluster of servers. Every namespace is a prefix in a bucket, and stateless query nodes cache what is being read on NVMe and in memory. The result is a different cost shape from most vector databases: data nobody queries costs roughly what object storage costs, and you pay per GB written and per GB scanned and returned instead of per operation.

This review covers the architecture, the ANN index, hybrid search, pricing as of October 2026 compared with Pinecone, where it wins, and where it breaks. I have not run turbopuffer in production, so every performance and cost figure below is vendor-published and labelled that way. For other approaches, see the reviews of [Pinecone](https://balazscsorba.com/blog/pinecone), [LanceDB](https://balazscsorba.com/blog/lancedb) and [Chroma](https://balazscsorba.com/blog/chroma).

## What it is

turbopuffer is a search engine that treats object storage as the database. The vendor describes the storage engine as an LSM on object storage, where “each search namespace is simply a prefix on object storage,” any node can serve any namespace, and a namespace reloads into cache after a cold query in about 500 ms ([turbopuffer](https://turbopuffer.com/blog/turbopuffer)). Object storage is not a cold tier you demote data to; it is where the data always lives.

The economics follow from the storage prices the vendor quotes: about $0.02 per GB for S3, about $0.60 per GB for triply replicated SSD, and “$2+ per GB” for in-memory vector databases, figures from 2022 ([turbopuffer](https://turbopuffer.com/blog/turbopuffer)). The founding case was Readwise, where more than 100 million documents would have cost over $20,000 a month in an in-memory store next to a relational database of about $5,000 a month. The vendor also reports that Cursor moved everything in a few days in November 2023 and saw costs drop 95 percent; Cursor’s side of that story is covered in [RAG over code](https://balazscsorba.com/blog/code-rag-repository-indexing).

The vendor’s own scale claims, undated on its site, are more than a trillion documents hosted, more than ten million writes per second and more than 100,000 queries per second across all customers. Treat those as marketing figures rather than a capacity plan; what matters for you is the per-namespace limits further down and the latency of the namespaces you will actually create.

## How it works

Queries go to stateless nodes that keep quantized centroids in memory and full-precision vectors on local NVMe. Warm queries never leave the node; cold ones fetch from object storage in a capped number of roundtrips. The vendor publishes these figures: for one million 768-dimensional vectors, about 10 ms p90 warm and 444 ms p90 cold; for a million-document BM25 index, 18 ms warm and 285 ms cold ([turbopuffer](https://turbopuffer.com/blog/turbopuffer)).

![turbopuffer query path Five steps from left to right: the client sends a query; a stateless query node takes it, and any node can serve any namespace; quantized cluster centroids are read from memory; full-precision vectors from local NVMe are used to rerank a small share of candidates; and for a cold namespace the data comes from object storage in about three roundtrips, after which it stays cached.](https://balazscsorba.com/images/blog/turbopuffer/diagram-8.webp?v=d4401d59c1)

Warm queries end in memory and NVMe; only cold namespaces reach object storage, which is the source of truth either way.

The current index, ANN v3, targets 100 billion vectors in a single index at 200 ms p99. It uses hierarchical clustering derived from SPFresh with a branching factor of 100, scans about 500 clusters per level, and stores vectors with RaBitQ binary quantization so that fewer than one percent of candidates need a full-precision rerank ([ANN v3](https://turbopuffer.com/blog/ann-v3)). The post states the arithmetic: one tree level is about 100 MB unquantized and about 6 MB quantized, which moved the bottleneck from disk to CPU. SPFresh itself is the SOSP 2023 design for incrementally updated cluster indexes ([SPFresh](https://dl.acm.org/doi/10.1145/3600006.3613166)).

Filters are part of the index rather than a post-processing step. Native filtering makes attribute indexes aware of the clustering, so the query plan can skip clusters with no matching documents and keep the number of candidates close to an unfiltered query ([turbopuffer](https://turbopuffer.com/blog/native-filtering)). Consistency is configurable: reads are strongly consistent against object storage by default and can be relaxed to eventually consistent queries under 10 ms ([docs](https://turbopuffer.com/docs/architecture)).

One query can use three signals. Full-text search is BM25 on the same engine, and the hybrid guide documents running vector and text queries and fusing the results before an optional rerank ([hybrid docs](https://turbopuffer.com/docs/hybrid)). Since 29 September 2026 turbopuffer can also create the embeddings itself instead of requiring you to bring your own ([native embedding](https://turbopuffer.com/blog/native-embedding)), which removes one service from the write path.

## Getting started

The natural unit is one namespace per tenant, per customer or per dataset, because namespaces are cheap prefixes and idle ones cost only storage. The sketch below writes rows with a vector and a full-text field and runs a filtered vector query and a BM25 query whose lists you fuse yourself; check the current client reference for exact parameter names before copying it.

```
# Sketch: one namespace per tenant, hybrid query with a filter (Python client)
import turbopuffer

tpuf = turbopuffer.Turbopuffer(region="gcp-europe-west3")
ns = tpuf.namespace(f"tenant-{tenant_id}")          # a prefix on object storage

ns.write(
    upsert_rows=[{"id": doc.id, "vector": doc.embedding, "text": doc.text, "lang": doc.lang}],
    distance_metric="cosine_distance",
    schema={"text": {"type": "string", "full_text_search": True}},
)

vector_hits = ns.query(rank_by=("vector", "ANN", query_embedding), top_k=50, filters=("lang", "Eq", "de"))
text_hits = ns.query(rank_by=("text", "BM25", query_text), top_k=50, filters=("lang", "Eq", "de"))
# fuse both lists (for example with reciprocal rank fusion), then optionally rerank the top 50
```

Namespace design is the decision that is hardest to change later. Per tenant is the usual default because it isolates data, makes deletion of a customer trivial and keeps each query small. Per dataset suits shared corpora such as a product catalog per language. Avoid one giant namespace for everything unless all queries really need all data, because scans and returned bytes are what you pay for, and filters inside a huge namespace still touch more of it than a small namespace would.

The documented limits are generous but real: up to 256 shards and about 128 billion documents per namespace, 10,752 dimensions, 8 vector columns, 64 MiB per document, around 10,000 writes per second and 5,000 or more queries per second per namespace, with recall at 10 between 90 and 100 percent ([limits](https://turbopuffer.com/docs/limits)).

## Pricing, and how it compares with Pinecone

As of October 2026 the pricing page lists a $16 monthly minimum for Launch, $256 for Scale, and at least $4,096 for Enterprise with a 35 percent usage premium ([pricing](https://turbopuffer.com/pricing)). The unit rates come from the page’s cost calculator rather than its prose, so treat them as calculator rates: about $0.33 per GB-month for indexed storage, $2 per GB written with a 10 kB minimum per write, and queries billed at $1 per PB scanned plus $0.05 per GB returned, with a minimum billed size per query.

![Two billing models side by side Two columns. turbopuffer bills GB stored, GB written, and GB scanned and returned by queries, with a monthly minimum. Pinecone bills GB stored, write units per million and read units per million, with an Enterprise minimum. The same workload therefore costs differently depending on how many bytes it moves versus how many operations it runs.](https://balazscsorba.com/images/blog/turbopuffer/diagram-19.webp?v=68b94e4adb)

Storage costs the same per GB-month in both; the difference is whether writes and queries are billed by bytes or by operations (calculator and pricing-page rates, October 2026).

Pinecone, on the same day, charged the same $0.33 per GB-month for storage but billed writes at $4 to $4.50 per million write units and reads at $16 to $18 per million read units on Standard, with a $500 monthly Enterprise minimum ([Pinecone](https://www.pinecone.io/pricing/)). The comparison is therefore not about storage but about the billing axis. Workloads with many small tenants, mostly idle data or large documents returned rarely tend to favour per-GB billing; workloads with many tiny queries against one hot index need the arithmetic done carefully, because per-query minimums apply.

Two more levers change the bill. Vector precision is priced: the calculator bills f16 vectors at half the storage of f32, and i8 at a quarter. Pinned namespaces, dedicated capacity for a hot namespace, cost $9.67 per GB-month with a 128 GB minimum per replica, sized at about 500 queries per second each. Pinning is how you remove the cold tail for the one namespace that cannot afford it.

The arithmetic works the same way as token costs in an LLM feature. On my own Nuxt site, where I run LLM features, the useful habit is writing the cost per request down from public prices before choosing a provider, and the same habit applies here: take a week of real query logs, estimate bytes scanned and returned per query, and price the identical week on both models.

## Where it breaks

The cold tail is the structural cost. A first query on a namespace that is not cached takes hundreds of milliseconds by the vendor’s own figures, which is fine for an agent tool call and noticeable in a search-as-you-type box. If your traffic spreads thinly over thousands of namespaces, many queries will be cold, so measure the share before promising latency.

**v3 is still being tuned**

turbopuffer is rebuilding its storage engine as v3, which according to the vendor now passes all tests. Its own nightly benchmark page currently shows v3 slower than production v2 at p90 on most workloads, for example about four times on hot full-text queries ([v3 benchmarks](https://turbopuffer.com/v3)). Ask which engine your namespaces run on and re-test after the switch.

Limits are the third consideration. A namespace tops out at 256 shards, and pinning is limited to 4 TB per machine and to accounts with at most 1,000 namespaces, so a product with tens of thousands of tenants cannot pin its way out of cold latency. Writes per namespace are capped around 10,000 per second, which matters for bulk re-embedding: plan large backfills as batched, throttled jobs rather than a single burst.

Vendor dependency is the other risk. There is no self-hosted edition in the sources here, every performance figure is self-published, and no independent benchmark turned up in my research. Keep the raw text, the embedding model name and the vectors in a store you control, so leaving means re-indexing rather than re-creating data.

## Alternatives

Aspect

turbopuffer

Pinecone serverless

LanceDB

Deployment

managed service

managed service

embedded library or cloud

Storage model

object storage as source of truth

managed serverless index

columnar files you own

Billing unit

GB stored, written, scanned, returned

GB stored plus read and write units

your own storage and compute

Multi-tenancy

namespace per tenant

namespaces

table or dataset per tenant

Best fit

many tenants, mostly idle data

steady traffic, simple ops

local or lakehouse workloads

The three differ more in operations than in search quality. Pinecone is the managed default with a per-operation bill and no cold-namespace behaviour to plan around. LanceDB stores vectors in columnar files you own and can run embedded inside your application or as a cloud service, which suits local and lakehouse-style workloads. Chroma, covered in [its own review](https://balazscsorba.com/blog/chroma), is the simplest start for prototypes and single-node apps. turbopuffer sits closest to Pinecone but with the object-storage cost model.

If you already run a search cluster, adding vectors there may beat all three, see [vector search in Elasticsearch and OpenSearch](https://balazscsorba.com/blog/elasticsearch-opensearch-vector-search). If the data is small and the team wants one database, [pgvector](https://balazscsorba.com/blog/pgvector) is the boring option worth pricing first.

## Verdict

turbopuffer is the most interesting cost model in managed vector search right now: object storage as the database, caches in front, and billing by bytes instead of operations. It fits multi-tenant products, agent memory and archive-like corpora where most data is idle and occasional latency in the hundreds of milliseconds is acceptable. It fits less well when every query must be fast on a long tail of rarely touched namespaces, or when you need a self-hosted option.

1.  Map tenants or datasets to namespaces and estimate how many are warm at once.
2.  Price a real week of traffic on both per-GB and per-operation models.
3.  Measure cold-query latency on namespaces of your real size.
4.  Test recall with your filters, not on unfiltered queries.
5.  Decide which namespace, if any, needs pinning.
6.  Keep source text and embeddings outside the service so you can leave.

If you are choosing a vector store for a multi-tenant RAG product and want the cost model worked out before you commit, see my [AI engineering work](https://balazscsorba.com/expertise/ai-engineer).

## Sources

1.  [turbopuffer blog: turbopuffer (updated Mar 2026)](https://turbopuffer.com/blog/turbopuffer)
2.  [turbopuffer blog: ANN v3 (Jan 2026)](https://turbopuffer.com/blog/ann-v3)
3.  [SPFresh (SOSP 2023)](https://dl.acm.org/doi/10.1145/3600006.3613166)
4.  [turbopuffer blog: native filtering](https://turbopuffer.com/blog/native-filtering)
5.  [turbopuffer docs: hybrid search](https://turbopuffer.com/docs/hybrid)
6.  [turbopuffer blog: native embedding (Sep 2026)](https://turbopuffer.com/blog/native-embedding)
7.  [turbopuffer docs: architecture](https://turbopuffer.com/docs/architecture)
8.  [turbopuffer pricing](https://turbopuffer.com/pricing)
9.  [turbopuffer docs: limits](https://turbopuffer.com/docs/limits)
10.  [turbopuffer v3 benchmarks](https://turbopuffer.com/v3)
11.  [Pinecone pricing](https://www.pinecone.io/pricing/)

## Frequently asked questions

What is turbopuffer?

A managed search engine for vectors and full text that stores every namespace on object storage such as S3 and serves queries from stateless nodes with SSD and memory caches. Cold data is cheap because it lives in object storage; hot data is fast because it is cached.

How much does turbopuffer cost?

As of October 2026 the Launch plan has a $16 monthly minimum and the Scale plan $256, with Enterprise from $4,096. Usage is billed per GB stored, per GB written and per GB scanned and returned by queries; the pricing calculator lists about $0.33 per GB-month for indexed storage and $2 per GB written.

How is turbopuffer different from Pinecone?

Both are managed and serverless, but they bill on different axes. Pinecone charges per million read and write units, turbopuffer per GB written, scanned and returned. turbopuffer also treats object storage as the source of truth, so latency on a cold namespace is higher than on a warm one.

Is turbopuffer fast enough for production search?

For warm namespaces the vendor reports p90 around 10 ms for a million vectors. The first query on a cold namespace is much slower, in the hundreds of milliseconds, while data loads into cache. Workloads that touch many rarely used namespaces should measure that cold tail.

Does turbopuffer support hybrid search?

Yes. It offers BM25 full-text search on the same engine, attribute filters that are aware of the vector clustering, and a documented pattern for fusing vector and text results before an optional rerank. Since September 2026 it can also create embeddings itself.

Written by Balázs Csorba

Senior fullstack & AI engineer in Styria, Austria – 10+ years of Vue, Nuxt, Node.js and PHP, now building tooling for AI agents.

[AI engineering & MCP servers →](https://balazscsorba.com/expertise/ai-engineer)[About me →](https://balazscsorba.com/about)

## More articles

-   [Choosing an embedding model in 2026: leaderboards, costs and a bake-off on your own data](https://balazscsorba.com/blog/embedding-model-selection-2026)
-   [Contextual retrieval and late chunking: giving RAG chunks back their context](https://balazscsorba.com/blog/contextual-retrieval-late-chunking)
-   [Access control for RAG: permission-aware retrieval without leaking documents](https://balazscsorba.com/blog/rag-access-control-permissions)
-   [RAG over product catalogues: turning PIM data into answers that hold](https://balazscsorba.com/blog/rag-product-catalog-pim-data)

## Sounds like what you need?

Tell me about your project or role – I’d love to hear from you.

[Get in touch](mailto:contact@balazscsorba.com) [Connect on LinkedIn](https://www.linkedin.com/in/balazs-csorba)