Use cases

Your agent is only as smart as the context it has access to; a mediocre model with the right context will outperform a frontier model with the wrong or no context. turbopuffer's object-storage-native architecture makes it possible to index many more documents at 10–20x lower cost than traditional search engines, so your agents can search every byte of context. turbopuffer gives agents fast search tools to narrow a corpus of millions or billions of documents to only the few documents they need at inference time.

If you're searching less than 1M documents, you probably don't need turbopuffer. You might not even need a dedicated search engine at all! As you scale past 10M+ documents, add more tenants, or need more isolated indexes, your current search system may not scale efficiently.

Most search systems treat indexes on local disks or memory as the source of truth. You provision clusters, shards, and nodes upfront, and cost and operational complexity grow with every new index, whether it is actively searched or not.

turbopuffer's object-storage-native architecture makes object storage the sole source of truth, with query nodes as stateless caches on top. Each namespace is a separate search index, created on first write as a prefix on object storage and fully decoupled from compute by default, which scales automatically to meet read and write demand.

Search indexes on turbopuffer are designed for object storage from first principles, minimizing round trips so cold queries stay reasonably fast and warm queries match in-memory performance. You do not need to plan capacity, bin-pack indexes, or run separate systems for vector and full-text search. If your current search system stops scaling efficiently as documents, tenants, or indexes grow, turbopuffer is a good fit.

Data isolation is a core requirement for multi-tenant products, especially in strictly regulated industries like healthcare, legal, and finance. turbopuffer delivers data isolation by default via isolated namespaces. There is no limit on the number of namespaces you can create, so you can create them at whatever granularity you need: globally, per customer, per project, per user, per agent. Each namespace is a separate search index that can be encrypted with a key that you or your customers control. Encryption happens at the namespace level, so every namespace can have its own encryption key. For stricter network boundaries, you can connect over private networking, restrict API access with IP allowlisting, or run turbopuffer entirely in your cloud with BYOC so customer data never leaves your VPC. turbopuffer regularly undergoes SOC 2 Type 2 audits and provides a Data Processing Addendum (DPA) to help customers comply with GDPR and CCPA requirements. Customers storing protected health information (PHI) may request a Business Associate Agreement (BAA) under which we commit to compliance with the requirements of HIPAA.

turbopuffer is designed to handle large corpora, whether in a single large namespace or a large number of smaller namespaces. A single-shard namespace can hold up to 500M documents at 1TB in logical size. Sharding multiplies that limit by 256. There is no limit on how many namespaces you can create. turbopuffer supports customers with over 1 trillion documents across 100M+ namespaces in production. Even if you have less than 1M documents now, if you expect to scale to 10M+, you should consider starting on turbopuffer to avoid a migration later. The Launch plan starts at $16/month, includes all database features, and scales with usage.

turbopuffer is designed to handle massive namespaces with consistent read traffic. A single namespace can hold up to 500M documents at 1TB by default. Sharding partitions one namespace across up to 256 internal shards, raising the ceiling of a single namespace to 256TB, enough to index a current snapshot of all the text on the internet for search.

turbopuffer is compute-storage flexible. By default, namespaces serve queries on shared multi-tenant node pools. For large namespaces with a sustained query rate, you can pin a namespace to reserved query nodes so its cache stays hot and latency stays predictable.

You can further scale read throughput with pinned replicas. Each replica runs on its own reserved query node and typically handles 100–1,000 QPS depending on query shape; throughput scales linearly as you add replicas. On a sharded namespace, pinning and replicas apply per shard, so an 8-shard namespace with 2 replicas reserves 16 query nodes. You can enable pinning, adjust replica count, or unpin at any time via the metadata API.

turbopuffer is not just a vector database, but a search engine with a unified API for dense vector search, sparse vector search, full-text search, regex search, attribute filtering, aggregations, faceting, and hybrid ranking. Different search tools work best for different tasks. Providing agents with access to many search tools in their harness expands their capabilities and improves efficiency over static RAG pipelines. We continually add new index types and search tools.

turbopuffer scales from zero to billions of documents and millions of namespaces without changing the operational model. You can add namespaces whenever you need them, and there is no limit on how many you can create. Each namespace is a new prefix on object storage, created implicitly on first write and fully decoupled from the compute layer, which turbopuffer scales transparently to meet read and write demand. You do not need to plan capacity, bin-pack indexes, or provision nodes as you add new namespaces. Queries and indexing use separate, auto-scaled node pools so heavy writes do not compete with reads. Pricing is based purely on usage, and each plan includes all database features at any scale.