The most valuable thing turbopuffer publishes is not its documentation, it is the write-up explaining why it exists, and I would recommend that piece to anyone working with retrieval regardless of which product they use. The argument goes like this. Conventional vector databases keep their indexes in RAM, because approximate nearest neighbour search over a large index is memory-bandwidth-bound and RAM is where you get bandwidth. That design produces excellent latency and a pricing model that follows directly from it: you pay for memory residency, continuously, for every vector you have stored, whether or not anyone queries it.
Then observe what the actual access pattern looks like for the dominant use case of vector search today, which is per-tenant retrieval over a customer's own documents. A user's codebase, workspace, email archive or document set sits completely dormant until that user opens the application. Across ten thousand customers, at any given moment, the overwhelming majority of your data is being queried by nobody. You are paying RAM prices, continuously, for data that is idle almost all of the time.
That is a genuine and substantial mismatch between a pricing model and a workload, and once it is pointed out it is difficult to unsee. turbopuffer's answer is a three-tier storage hierarchy: cold data lives on object storage at roughly two cents per gigabyte, warm data is cached on NVMe SSD, hot data sits in memory, and data promotes upward as a namespace is queried. You pay near-nothing for dormant data and pay properly when you actually use it. Against RAM-resident architectures, the storage cost difference for a storage-heavy, moderate-query workload is not a percentage, it is roughly an order of magnitude.
That is a real engineering result rather than a pricing gimmick, and the write-up explains the mechanics well enough that you could reason about whether it applies to you. The pricing trajectory is worth a note because it runs against the industry grain. Queried data rate dropped from five dollars per petabyte to one in February 2026, and the entry minimum fell from sixty-four dollars to sixteen in June 2026. Infrastructure vendors usually move the other way once adoption is established, and repeated reductions suggest the cost structure genuinely improved rather than a land-grab being funded by someone's balance sheet.
I would still model your own workload rather than trusting a trend. The honest limitation is the direct consequence of the design and the documentation is reasonably upfront about it. If a namespace has been cold and the data is sitting on object storage, the first query has to fetch it, and that is slower than querying an index already resident in memory. Steady-state latency once warm is good, with sub-ten-millisecond median figures quoted.
The cold path is not, and no amount of caching cleverness eliminates the physics of fetching from object storage. Whether this matters depends entirely on your product. If a user opens your application, waits a moment for their workspace to become responsive and then issues many queries, the first-query cost is amortised across the session and is invisible. If you are serving a latency-sensitive endpoint where every request might hit a different dormant namespace, you have chosen the wrong architecture.
Work out which you are before committing, and test it rather than reasoning about it. The economics case also weakens sharply in the uniformly hot, high-query-rate scenario. If all your data is queried constantly, tiered storage gives you nothing, everything ends up promoted, and you are paying for a cache hierarchy you are not benefiting from. The architecture is optimised for a specific and common access pattern, not for all of them, and a buyer should establish which one they have rather than adopting the general conclusion that object-storage search is cheaper.
The significant structural caveat is that turbopuffer is proprietary and closed source. There is no self-hosting, no inspection of the implementation, and no exit path other than re-indexing your vectors into something else. For a search index this is a less severe form of lock-in than it would be for a system of record, since vectors can be regenerated from source documents given enough compute and patience, but it is lock-in nonetheless and the absence of any open alternative implementing the same architecture means you cannot hedge. Compare this with Typesense, where the GPL binary means the worst case is that you run it yourself.
As teaching material, the documentation itself is thin. It is terse and accurate, which I prefer to padded and vague, but there is no course, no learning path, no conceptual introduction to retrieval for someone who does not already have one, and very little beyond the API reference and the architecture post. The product is also young and the community correspondingly small, so the stack of accumulated answers to unusual problems that you get with an established project does not yet exist. Three point seven.
An excellent free architecture write-up attached to a genuinely differentiated product with an honest cost story, marked down for closed source with no exit, thin material beyond the one good post, and cold-path latency that rules it out for a real class of workloads.