Turbopuffer replaces Elasticsearch and pgvector

Linear’s switch shows that turbopuffer wins when search stops being a feature and starts being infrastructure cost. The important point is not just that it was cheaper, it is that one managed system replaced two different pieces of search plumbing, Elasticsearch for keyword retrieval and pgvector for embeddings. That cuts vendor sprawl, removes cluster work, and makes hybrid search feel like one database instead of an integration project.

• This is the incumbent pattern in practice. Elasticsearch is powerful, but teams usually inherit shards, index tuning, and a separate vector layer. Linear replaced that mixed stack with turbopuffer and reported about 70% lower cost, which makes the displacement case concrete instead of theoretical.
  1 turbopuffer
• The economic edge comes from workload shape. Turbopuffer keeps hot data in fast cache and colder data in object storage, so products with large corpora, uneven traffic, and per tenant access patterns avoid paying memory prices for rarely touched documents. That is exactly where Elasticsearch and pgvector become expensive to overprovision.
  2 sacra 3 sacra
• The tradeoff is that turbopuffer is best when relevance is good enough without deep ranking customization. Related interviews show teams still prefer Vespa or Elasticsearch for heavy personalization, exact token matching, or complex hybrid ranking. Turbopuffer is strongest as the simpler default for generic agent and workspace search.
  2 sacra 3 sacra

Going forward, more search migrations should look like Linear’s. The next wave is not teams adding a vector database beside Elasticsearch, but teams collapsing keyword and vector search into one lower ops system. That shifts competition away from pure relevance features and toward total workload cost, deployment friction, and how much search infrastructure a product team has to own.