Buying snapshot
Scroll sideways to see all columns. With a keyboard, focus this table and use the arrow keys.
| Decision point | What Turbopuffer states |
|---|---|
Search types | Vector search (approximate nearest neighbor), BM25 full-text search and hybrid search, plus metadata filtering. |
Access | HTTP API with an API key. You choose a region when you create a client; the Python README example uses gcp-us-central1. |
Published limits | Per namespace: up to 128B documents at 256 TB, 10k writes/s at 32 MB/s, and 5k+ queries/s. No limit on total documents or on the number of namespaces; up to 256 pinned namespaces. |
Vector recall | 90-100% recall@10 for vector search. |
Python client | Official client under the MIT license, for Python 3.10 or higher, with synchronous and asynchronous clients. |
Our take
Choose Turbopuffer when you want vector, full-text and hybrid search from one API, expect to spread data across many namespaces, and can estimate a usage-based bill from your own write, storage and query volumes.
Evaluate Turbopuffer
Popular comparisons
See all 7 Turbopuffer comparisons
Where it stands out
One query call for three kinds of search. Vector ranking and BM25 text ranking go through the same query call with the same filters, and hybrid search combines the two. That can save running a separate keyword engine next to a vector store.
Large deployments on record. Turbopuffer says production systems on it handle 1T+ documents, 10M+ writes/s and 100k+ queries/s. It reports seeing 250M+ namespaces and a single namespace with 100B documents at 200 TB.
A typed client that handles routine failures. The Python library retries connection errors, timeouts, 409 conflicts, 429 rate limits and 5xx errors with exponential backoff, pages through list results for you, and can use aiohttp for better concurrency.
Product screenshot
Trade-offs to weigh
Warm and cold namespaces perform very differently. In Turbopuffer's own benchmark (1024 dimensions, 10M documents, about 40 GB, 8 queries/s, top 10 results), p50 latency was 14 ms on a warm namespace and 874 ms on a cold one; p99 was 27 ms and 1,686 ms. If users often query rarely used data, test with your real access pattern.
Schema choices add billable volume. With several vector columns, filterable attributes are billed once per vector column for writes and storage; non-filterable attributes are billed once. Late-interaction attributes bill per-token vectors at the non-filterable rate (50% of logical size), add about 10 KB per document for the index, and count each late-interaction ANN query as two queries.
Pricing rules change often. The pricing changelog has entries for February, March, April, June, August and September 2026. Most lowered costs or priced new features, but the pinning minimum went up. Check the current rules before you set a budget.
Pricing and plan conditions
Turbopuffer bills by usage. Its pricing changelog describes charges for writes, storage and queries, with queries billed by the amount of data queried and pinned namespaces billed by GB-hours instead. Full billing details are on Turbopuffer's pricing page, and Turbopuffer asks you to contact it for help estimating the impact on your workload.
Scroll sideways to see all columns. With a keyboard, focus this table and use the arrow keys.
| Item | Current rule |
|---|---|
Launch plan minimum | $16 per month. If your usage in a month is $16 or less, you pay $16; above that, you pay for usage. Cut from $64 in June 2026 for new and existing Launch customers. |
Queried data | Base rate $1/PB, with a marginal discount of 80% for queried data between 32 GB and 128 GB and 96% above 128 GB (set in February 2026). |
Minimum billed per query | 1.28 GB of queried data (raised from 256 MB in February 2026). |
Namespace pinning | Billed in GB-hours instead of per-query TB Queried pricing; cost scales with namespace size, replica count and time pinned. Minimums are 10 minutes and 128 GB: a smaller pinned namespace is billed as 128 GB (raised from 64 GB in August 2026). |
Copying between namespaces | copy_from_namespace is charged at a 50% discount on write costs. |
Public signals
About these signals
Verified factual signals from public sources. They indicate observable activity or interest, not total adoption, product quality, or cost.
60 GitHub commits 90d187 GitHub stars0 vulnerabilities across 2 packages
See all signals from 6 sources
npm · @turbopuffer/turbopuffer@2.14.0 · PyPI · turbopuffer@3.1.0
Alternatives to Turbopuffer
The reviewed substitutes for Turbopuffer among the vector databases, and what would make each one the better answer.
Direct alternatives
Reviewed substitutes: products bought for the same job, where a team picks one.
- Pinecone
- Pinecone and Turbopuffer are commercial serverless services for vector search, so neither needs a cluster to manage. Pinecone is a purpose-built vector database for production AI, while Turbopuffer pairs vector and full-text search on object storage with a memory and SSD cache and stresses low cost at scale.Applies to: Choosing a vector store for embedding search in a retrieval or agent application.
- Qdrant
- Qdrant and Turbopuffer run vector search with filtering for production retrieval and search features. Qdrant is open source and can be self-hosted or used in Qdrant Cloud, while Turbopuffer is a commercial serverless service that also does full-text search and stores data on object storage.Applies to: Choosing between these two for the vector databases decision.
- Weaviate
- Weaviate and Turbopuffer both run vector and keyword search for AI products. Weaviate is open source, so teams can host it themselves or use its managed cloud, while Turbopuffer is a commercial serverless service that keeps data on object storage to hold down the cost of large indexes.Applies to: Choosing between these two for the vector databases decision.
- Zilliz
- Zilliz and Turbopuffer are hosted vector search services, so teams run large-scale similarity search without managing clusters. Zilliz is built on the open-source Milvus database by its creators, while Turbopuffer is a serverless engine for vector and full-text search that stores data on object storage to keep large indexes low in cost.Applies to: Choosing between these two for the vector databases decision.
- LanceDB
- LanceDB and Turbopuffer are vector search engines that keep data on object storage so large indexes stay affordable. LanceDB is open source, with a multimodal data format and native versioning that also suits AI training data, while Turbopuffer is a commercial serverless service for vector and full-text search with a memory and SSD cache in front of object storage.Applies to: Choosing between these two for the vector databases decision.
Other approaches
A different approach to the same problem. Each substitutes only for the workload named beside it.
- ChromaDB
- ChromaDB is used rather than Turbopuffer for prototype RAG workloads built around LangChain or LlamaIndex. We recommend ChromaDB over Turbopuffer for teams building and iterating on Python-based RAG applications that need direct framework integration.
- Marqo
- Marqo optimises search conversion using click-stream, purchase and event data, creating a personalised experience that knows what your customers are looking for - better than they do.Applies to: For teams that build their own product search on a vector store rather than buying a hosted ecommerce search platform.
- Vald
- Vald is preferred over Turbopuffer for self-hosted Kubernetes vector-search workloads requiring distributed indexing and infrastructure control. We recommend Vald over Turbopuffer when Kubernetes is the required operating environment and teams can manage the supporting cluster infrastructure.