Turbopuffer

• CategoryManaged SaaS
• EngineRust
• PricingPaid
• LicenseProprietary
• Created2024
• GitHub starsclosed
• Hybrid searchNative
• Edge-readyYes
• Multi-tenantNative
• Max dimensions20,000

Turbopuffer is a newer serverless vector database that stores vectors in object storage (S3-class). Pay-per-query rather than always-on cluster cost, kindest pricing model for sparse-traffic workloads. Used by some serious AI products in production despite being ~2 years old.

• Sparse-traffic RAG workloads where always-on cluster cost is the constraint
• Apps with bursty query patterns
• Teams that want managed vector without Pinecone-tier pricing

Skip Turbopuffer for very steady high-throughput workloads, at sustained traffic the per-query model loses to a dedicated cluster. Skip if you want the breadth of Pinecone's feature surface.

Turbopuffer is the most interesting newer entrant. Object-store-backed is the right architecture for sparse-traffic AI; the bet is whether the team can stay independent or get acquired.

Most vector databases charge you for capacity you provisioned. Turbopuffer charges closer to the work you actually did. Vectors sit in object storage, hot data is cached on faster media, and a namespace nobody queried this week costs little beyond the bytes it occupies. For a product with a thousand customers where each customer's corpus is queried a few times a day, that is the difference between per-tenant indexes being viable and being unaffordable. The consequence is a latency profile with two modes. A query against warm data is fast; a query against a namespace that has gone cold pays to fetch from object storage first. Whether that matters depends entirely on your access pattern, and it is the first thing to measure in a trial rather than the last thing you discover in production.

Turbopuffer is proprietary and newer than everything else in this directory. There is an enterprise arrangement that deploys into your own cloud account, which helps with data residency, but the software stays the vendor's and they operate it, so it is not a self-host escape hatch in the sense that Qdrant or Weaviate offer one. That is a real risk to price in, and the standard mitigations apply: keep source documents and embedding code outside the service, and know what re-ingesting into Qdrant or pgvector would cost in engineering days. The counterweight is that serious AI products already run production traffic on it. There is also a functional gap worth checking early, because the feature surface is narrower than Pinecone's.

• Official homepage →

The 30-min call is where your vector-DB choice becomes a real RAG architecture, a chunking + reranking strategy that actually works for your corpus, and a price range you can take to your stakeholders. Describe your data shape, your query patterns, your latency budget. I tell you whether Turbopuffer is genuinely your fit.