Turbopuffer becomes hybrid retrieval layer

Adding full text and hybrid search turns Turbopuffer from a cheap vector store into a system agents can actually rely on for real work. Agent workflows do not just need documents that feel semantically related. They need exact strings like class names, ticket IDs, customer names, and error codes, then need those exact matches blended with vector recall. That is why retrieval is moving toward a two step job of broad candidate fetch, then ranking, and why Turbopuffer is expanding toward the retrieval layer rather than staying only a vector database.

• In practice, dense retrieval alone breaks on code and enterprise records. Engineers evaluating Turbopuffer found that code search depends heavily on exact token matches and freshness, which makes sparse and hybrid retrieval necessary for repositories, docs, tickets, and changing internal data.
  2 sacra
• The product wedge is that hybrid retrieval can be offered inside a cheaper storage model. Teams using Turbopuffer in production describe it as good enough for many generic agent workloads because hot data stays cached for fast queries while colder data sits in object storage, lowering total cost on large corpora and spiky traffic.
  3 sacra 1 sacra
• This positions Turbopuffer differently from web search APIs like Exa and from ranking heavy systems like Vespa. Exa helps agents search the public web, while Vespa is preferred when teams need deeply customized ranking and personalization. Turbopuffer fits the middle, the internal retrieval engine that fetches candidate records cheaply across massive private datasets.
  3 sacra 4 sacra

The next step is deeper control over ranking signals, freshness, and policy aware filtering. If Turbopuffer keeps improving hybrid relevance while preserving its cost advantage on large cold datasets, it can become the default backend for agent products that search a company’s own code, docs, and records before the model decides what to do next.