Turbopuffer continues to demonstrate they have both the product conviction and technical chops to build an unbeatable vector database service, nobody else seems close. If you haven't been paying attention yet, you should. tl;dr - graph go down
brandCooling
Turbopuffer on X
Talk about Turbopuffer is largely praise — plain enthusiasm and admiration for the engineering — with 5 people slotting it into their stack and 4 reporting speedups after switching. The open questions are technical: how the binary-quantization speedup works and whether the latency numbers hold.
First written 27 Oct · what changed · from 55 posts by 49 people
Tracking posts that say “turbopuffer”
Track this for your marketPosts, last 24h
15
+200%vs. previous 24h
Posts, last 7 days
153
32 in the last 72h
Velocity
22/day
7-day average
Momentum
−31%
Last 24h vs. a normal day this week
Posts per day, last 30 days
as of Nov 3, 10:00 UTCWhat changed
as of 27 Oct · checked once a monthFirst written 27 Oct. When what people say changes, it shows here.
Tone· 33 posts from 30 people· written 27 Oct
How do people feel about Turbopuffer?
The largest group, 11 people, praise turbopuffer plainly; 8 admire the engineering behind it and 5 describe it as the search layer they slot into their own stack. 4 report a large speedup after switching.
The plain praise is short and confident: "solid", "a beauty", "super cool", and from one account crediting "product conviction and technical chops", adding "nobody else seems close". Another likes that it makes retrieval "boring to operate". A smaller group digs into how it is built — one singles out NVMe being treated as part of the cache, another the RaBitQ pruning that skips full-precision reads when a candidate cannot beat the best so far, and one notes that new embedding models show up on release day, so there is "no embedding provider to wire up".
5 people treat it as the obvious search layer in their own setup: one sketches a stack of Postgres, S3, then turbopuffer for "better search and indexing"; others use it for personal knowledge management, agent memory, or blended keyword and vector search.
4 report results after moving. One team's review tables now load "up to 5.8x faster" behind a turbopuffer query layer, another says the same query runs 10x faster on exact kNN, and a third wishes they had "switched much earlier". Two people draw a size line, saying it suits large datasets and low top-k.
- Enthusiastic praise11
- Admires the engineering9
- The obvious place in the stack7
- Switched and it paid off4
- Better on large datasets2
See 5 of 33 postsHide the posts
Product conviction without latency discipline ends up as a benchmark tool. Turbopuffer earns trust by making retrieval boring to operate.
memory/cache hierarchy from the fastest to the slowest @turbopuffer considers NVMe as part of the cache, which is becoming quite common for cloud native object storage solutions. #P99CONF @P99CONF Every developer should keep these in mind.
It all starts with Postgres. So innocent. Then S3 for your blobs. Then Turbopuffer for better search and indexing. Then ClickHouse with Postgres CDC because your analytical queries are going parabolic Now you're reading fuckin Kafka documentation
Review Tables now load up to 5.8x faster in Harvey. Our engineering team built server-side pagination to support larger reviews without loading the entire table into browser memory. That required: - A Turbopuffer query layer for server-side sorting and filtering - Custom row-ID pagination and staged loading - Typed and string fields to handle inconsistent model outputs - Fallback reads and backfill jobs to recover from data drift
5 of the 33 posts behind this answer, one per person. The other 28, and every new one as it’s posted, come with tracking. Get early access
Pain points· 4 posts· written 27 Oct
What do people complain about with Turbopuffer?
There is little complaint, and no single problem dominates: 2 people raise migration pain and 2 say search missed what they wanted. Each is a small, separate gripe rather than a pattern.
The migration complaint is about embedding models. Because changing the embedding setting does not re-embed documents already stored, switching models means re-ingesting whole namespaces; one person notes that new query vectors need documents embedded with the matching model, and advises treating a model upgrade "as a corpus migration". Another, watching a company move services, says "migrations are annoying, with or without AI".
The other complaint is about result quality. One person indexed a knowledge repo and found semantic search "gave noisy results, especially for supersed things"; they tried timestamp boosting and separate namespaces before retiring the index. Another points to what the docs say about truncation — anything longer than the model can read at once is "cut off at the start", so chunking long documents matters more than a recall gain.
No theme here is new, rising, fading or quiet, and price and support do not come up.
- Migrations are painful2
- Search misses the right results2
See the 4 postsHide the posts
This is massive! Happy for @jeffreyhuber and co. this is a really good acq for Replit and excited for what they do together ...but I imagine it would be insanely hard for the transition of folks to other services (read: turbopuffer) migrations are annoying, with or without AI
Nemotron-3.5-Embed is now in turbopuffer, but changing the embedding setting won't re-embed stored documents. The docs say to re-ingest them. Treat a model upgrade as a corpus migration: new query vectors need documents embedded with the matching model.
No secrets ;). Original knowledge index idea in Everruns is that knowledge is stored in github repo, Everruns indexes (turbopuffer) it and exposes search across this index. I had a deployment for support agent, but it was quite bed. Semantic search gave noisy results, especially for superseeed things. I did couple of iterations of implementing timestamp boosting, namespaces, and eventually gave up. At this point I retired knowledge index, and instead I have agents that just mount knowledge repo and use grep and progressive disclosure. I will probably add some optimization and some search in future. No evals for knowledge index in Everruns. On other projects we mostly were evaluating precision@k and recall@k, both are quire useless if your agent can do mutiple steps. What choices do you face?
their docs say anything longer than the model can read at once gets cut off at the start, so on long docs how you chunk matters more than the 5%. worth running on your own pdfs
Alternatives· 4 posts· written 27 Oct
What are the alternatives to Turbopuffer?
4 people each weigh turbopuffer against something else, and no option is shared: HydraDB for agent context, an in-memory scan or SQLite, running embeddings yourself, or letting agents grep a mounted repo. Each is one person's route, not a trend.
The most concrete comparison is against not using a vector database: one person calls a specialised vector database "complete overkill" below about 100,000 vectors, where an exact scan in memory or SQLite is sub-second and "completely costless", and argues the need for distributed infrastructure is a vendor narrative. That same person draws turbopuffer's size line in reception.
Two routes come from people building without turbopuffer's built-in embeddings. One used voyage-4-nano with a port of JVector to Rust, does not recommend that route, and guesses 80k function embeddings would not cost much on turbopuffer anyway. The other weighed turbopuffer against HydraDB, saying tools for agent context are "trash" unless built on something like the latter.
The fourth drops search altogether: after noisy semantic results, that person retired the turbopuffer index and has agents mount the knowledge repo and grep it with progressive disclosure, leaving open the option of adding search back later.
- HydraDB1
- SQLite or in-memory scan1
- Doing embeddings yourself1
- Grep over a mounted repo1
See the 4 postsHide the posts
Setting up a specialized vector database like pinecone/turbopuffer is complete overkill for almost any engineering dataset under 100,000 vectors. For anything under that 100,000 cutoff, an exact scan in memory or SQLite is sub-second and its also completely costless. There's a persistent narrative driven by vendors that you need distributed infrastructure the second you touch embeddings. But brute-force array math is fast enough for the vast majority of retrieval tasks people are actually building right now. in general i think this principle applies that we spent a lot of time provisioning external infra before checking whether local math solves the problem first.
I did this with voyage-4-nano and a vibecoded port of JVector to Rust, but I don't exactly recommend that route. I have no idea what 80k function embeddings costs on turbopuffer but I have to imagine not much?
You guys using vector database (turbopuffer) built for humans or something like hydradb? Instinct, muse, dots are all trash with context unless built on the latter. Will continue to use my agents built the right way until things are built the proper way
No secrets ;). Original knowledge index idea in Everruns is that knowledge is stored in github repo, Everruns indexes (turbopuffer) it and exposes search across this index. I had a deployment for support agent, but it was quite bed. Semantic search gave noisy results, especially for superseeed things. I did couple of iterations of implementing timestamp boosting, namespaces, and eventually gave up. At this point I retired knowledge index, and instead I have agents that just mount knowledge repo and use grep and progressive disclosure. I will probably add some optimization and some search in future. No evals for knowledge index in Everruns. On other projects we mostly were evaluating precision@k and recall@k, both are quire useless if your agent can do mutiple steps. What choices do you face?
Questions· 13 posts from 12 people· written 27 Oct
What do people ask about Turbopuffer?
The largest group of questions is technical: 4 people ask how the binary-quantization speedup works and where it applies. 2 ask what to build with it at all, and smaller pairs ask whether the latency numbers hold, whether a 5% recall gain matters, and whether switching is worth it.
The binary-quantization questions are the largest group but still narrow: how the speedup works at all, whether the win holds for large result sets or the cutoff gets "too loose to skip much", whether skipping rows before the filter beats predicate pushdown, and whether binary quantization is coming to multi-vector.
Next, two people are still hunting for the point of it — one replies that they are "still busy looking for a usecase" and asks what product to build next that has search.
Simultaneously, two people push back on the numbers. One asks what explains the remaining latency gap, noting 84ms is still about 5x the production p90 figure; the other asks whether p99 went up. Two more ask how a recall@20 improvement holds on longer documents and whether it is enough to matter for enterprise queries.
Two people ask whether it is worth adopting: what others switched from, and whether it is a viable option alongside other tools.
- How does binary quantization work?4
- What's the use case?3
- Is the latency really that low?2
- Is a 5% recall gain meaningful?2
- Is it worth switching to?2
See 5 of 13 postsHide the posts
does the win hold for large result sets, or does the cutoff get too loose to skip much?
Did you try skipping rows before they even hit the filter, or is the filter doing the skip? Curious if early exit beats predicate pushdown here.
Will binary quant be coming to multi-vector?
im still busy looking for a usecase
Nice cut! 84ms is still about 5x your prod number at p90 though. What's eating the rest of the gap?
5 of the 13 posts behind this answer, one per person. The other 8, and every new one as it’s posted, come with tracking. Get early access
Wishes· 3 posts· written 27 Oct
What do people want from Turbopuffer?
Three people, three different wishes, none shared: re-embed stored documents when the model changes instead of re-ingesting, keep the original BM25 score next to the reranker's, and a Canadian region.
The clearest wish is about model swaps. One person says the scary part of picking is that swapping the embedding model later re-embeds nothing, so you "re-ingest the whole namespace", and that is the bit they want next.
Another wants more visible ranking: in the computed-attribute example, $dist switches to the reranker's score, and keeping the original BM25 score alongside it would make it easier to see which documents the model promoted or pushed down.
The third is about location: one person reports that turbopuffer "doesn't support montreal" and asks for a northamerica-northeast2 (Toronto) region, in a reply about another service.
Nothing else is asked for. No one asks for a lower price, a different query language, or self-hosting.
- Re-embed instead of re-ingesting1
- Keep the original BM25 score1
- A Canadian region1
See the 3 postsHide the posts
the scary part is still picking: docs say swapping the model later doesn't re-embed anything, you re-ingest the whole namespace. that's the bit i'd want next
The computed-attribute example is a useful debugging detail: $dist switches to the reranker’s score. Keeping the original BM25 score alongside it would make it easier to see which documents the model promoted or pushed down.
can we get @PlanetScale on northamerica-northeast2 (Toronto)? @turbopuffer doesn't support montreal :(
Posts are shown the way X shows them. One of them yours? Here’s why it’s shown, and how to take it off.
Also in Vector databases
Get every post about Turbopuffer, filtered and labelled
This page is the summary. Tracking gives you the stream behind it for any brand, keyword or @mention: each new pain point, request and question as it’s posted, with the spam and promotions already taken out.