_peregrine_

as a tpuf employee i can say we feel very well represented in this article. author did a really nice job. good read too

confirmed - we still write by hand

instant bookmark!

this is actually not how cursor uses turbopuffer, as they index per codebase and thus need many mid-sizes indexes as opposed to one massive index as this post describes

unfortunately i'm not able to share the customer or use case :( but the metrics that you see in the first charts in the post are from a production cluster

the solution described in the blog post is currently in production at 100B vectors

seems like a good rule of thumb to me! though i would perhaps lump "cost" into the "until it breaks" equation. even with decent perf, pg_vector's economics can be much worse, especially in multi-tenant scenarios where you need many small indexes (this is true of any vector db that builds indexes primarily on RAM/SSD)