Turbopuffer Best for Dense Retrieval
AI engineer at Meta on evaluating Turbopuffer vs. Pinecone vs. Weaviate
This draws a clean line between retrieval engines that are good candidate generators and search systems that double as full query planners. Turbopuffer is strong when the job is, turn text into embeddings, find nearby vectors, and hand the top matches to a separate ranker. Once the workload needs exact token matching, complex metadata logic, or one engine that handles both retrieval and ranking, Elasticsearch and Postgres become more useful because they expose more control over sparse search and schema heavy filtering.
-
The interview frames Turbopuffer as good enough for pure dense retrieval, but weaker when teams need sparse fallback. That matters in code search, where class names, project names, and fresh tokens break pure semantic matching and push teams toward hybrid systems.
-
Postgres shows up as the practical fallback when metadata gets messy. Nested JSONB fields, custom schema syntax, and tight coupling to application data are easier to express in Postgres, especially for smaller corpora where keeping more data in memory keeps retrieval fast.
-
Turbopuffer has been expanding beyond pure vectors, with BM25, sparse vector search, and nested boolean filters now available. That narrows the feature gap, but the core fit still centers on large, cost sensitive corpora where dense retrieval is the main job and object storage economics matter more than maximum query flexibility.
The likely direction is that Turbopuffer keeps moving up from pure vector retrieval into hybrid search, while incumbents move down from full search stacks into cheaper vector storage. The battleground will be teams that want Pinecone like simplicity, Elasticsearch like query power, and Postgres like schema flexibility in one system, without giving up predictable latency.