The vector database market is hitting an inflection point. turbopuffer is now handling 4+ trillion documents, sustaining 10+ million writes per second, and serving 25,000+ queries per second in production. Those are not benchmark numbers cooked up for a launch blog post. Those are live workloads running today. The question for engineering leaders is not whether turbopuffer works at scale. The question is whether your team is still paying 10x more than you need to for search infrastructure.

turbopuffer is a vector and full-text search database built from first principles on top of object storage (S3-style backends). It supports both semantic vector search and traditional keyword search in a single system, with index structures and embeddings living on S3 rather than on always-on SSD or DRAM clusters. That architecture distinction matters more than any feature list. Almost every competing system, whether Pinecone, Qdrant, Milvus, or Elasticsearch, was designed to keep indexes hot in memory or on fast local NVMe. That made sense in 2018. In 2026, when most AI workloads involve large cold corpora queried in bursts, paying for always-on cluster capacity is the wrong default. turbopuffer's design inverts that assumption. Cold data lives cheaply on S3. Hot query state gets pulled into faster tiers on demand. The result is a pay-per-query model that scales down to near-zero when no one is searching, and scales up to tens of thousands of QPS when they are.

Let's be specific about what "production scale" means here:

That last number is the most revealing. Eighty million namespaces is not a single enterprise search deployment. That is a multi-tenant architecture at SaaS scale, where each customer or document collection gets its own isolated namespace. This is the retrieval layer for AI products that need per-tenant isolation without paying per-tenant infrastructure costs. For context: running 80 million namespaces on a traditional always-on vector database would require either an absurd amount of hardware or a complex tiering system you'd have to build yourself. turbopuffer's S3-native design handles this natively because storage is cheap and compute is ephemeral.

The ~10x cheaper positioning is not just marketing math. One customer migration story reports embeddings stored 20x cheaper than their previous vector storage setup, while still supporting hybrid retrieval combining embeddings with trigram search for exact text matching. That's the combination that most teams actually need: semantic similarity for "find me things related to X" and keyword/exact match for "find me things containing the string Y." Building that hybrid stack on top of Elasticsearch plus a separate vector database, or on pgvector with custom trigram indexes, is a real engineering project with real ongoing operational cost. turbopuffer ships both in one system, backed by S3. The business validation is equally hard to argue with. turbopuffer reached $100M ARR in 19 months with under $1M invested. That ratio, roughly $100 of recurring revenue for every $1 of capital deployed, is essentially unheard of in infrastructure software. It signals genuine product-market fit, not growth purchased with sales headcount.

Most coverage will position turbopuffer against Pinecone, Weaviate, or pgvector. That framing misses the more important competitive dynamic. turbopuffer competes as much with Amazon OpenSearch, Elasticsearch, and DIY FAISS/ScaNN pipelines as it does with purpose-built vector databases. The relevant comparison is not "which vector DB has the best HNSW implementation" but "what is the total cost to run search infrastructure for an AI product at scale."

The "cold corpus cost" column is where turbopuffer wins decisively. For workloads where 80-90% of your document corpus is rarely queried but must be searchable, paying always-on cluster costs is pure waste. turbopuffer eliminates that waste structurally. Where competitors remain credible: latency-sensitive workloads with very hot data, or cases where you need tight integration with an existing Postgres or Elasticsearch operational stack. If your p99 latency requirement is sub-10ms and your corpus is fully warm, turbopuffer's S3 read overhead may not fit. Be honest about your actual workload before switching.

Cost reduction is the obvious headline. The more durable value is operational leverage. Today, teams running large-scale AI search products spend engineering cycles on:

turbopuffer's architecture offloads most of that to the service. Multi-tenant isolation is a namespace parameter, not a cluster topology decision. Durability is S3, not a replication configuration you own. Cold storage tiering is automatic, not a custom pipeline. The engineering time that gets reclaimed does not disappear. It redirects toward problems that actually differentiate your product: data modeling, embedding selection, recall evaluation, ranking logic, and retrieval-augmented generation pipeline quality. These are the problems where engineering effort compounds into product quality. Cluster operations do not. For smaller teams and startups, the implication is even sharper. A two-person AI engineering team can now ship production-grade hybrid search over a billion-document corpus without hiring a search platform engineer. That was not realistic in 2024 without either significant infrastructure investment or accepting Elasticsearch's operational overhead.

This is not a "watch and see" situation for most teams. Here is how to think about timing:

Adopt now if:

Run a pilot first if:

Specific pilot path: Start with an internal workload. Support ticket search, internal wiki RAG, or log/event embedding search are ideal candidates. These have lower latency pressure than customer-facing search, real query volume, and real cost you can compare. Run it for 30 days. Measure p50/p99 latency, cost per million queries, and operational time spent. Then you have real numbers, not marketing comparisons.

turbopuffer's traction accelerates a broader architectural reckoning that was already underway. If an S3-native system can deliver the advertised 10x cost reduction at trillion-vector scale while meeting interactive latency SLAs, it puts pressure on every incumbent to decouple index lifecycle from hot serving. Elasticsearch and OpenSearch have been adding vector search capabilities, but their core architecture is designed around always-on cluster nodes. Pinecone has serverless offerings, but the economics still reflect a system designed before object storage costs collapsed. Milvus has S3-backed storage options but was not designed storage-first. The pressure is real. Incumbents will respond, some already are. But turbopuffer has a head start measured in production deployments at a scale most competitors have not reached in their entire customer base.

turbopuffer is not a vector database you evaluate alongside Pinecone and Qdrant and pick based on a feature checklist. It is a different architectural bet: that the right default for AI-scale search is storage-first, not compute-first. The evidence that this bet is correct is already in production. Trillions of documents. Tens of thousands of QPS. A $100M revenue run-rate reached faster and with less capital than almost any infrastructure company on record. For engineering leaders running AI products at scale, the action is clear: identify your highest-cost, cold-corpus search workload, run a turbopuffer pilot against your current stack, and measure the result. If the 10x cost reduction holds for your workload, you have a straightforward infrastructure decision. If it does not, you will know exactly why and what tradeoffs you are making. The era of paying always-on cluster costs for mostly-cold search workloads is ending. The only question is whether your team gets ahead of that shift or waits until your infrastructure bill forces the decision.

Want to start building with turbopuffer? Here's a quickstart: