Querying 3B Vectors

Jeff Dean shoutout triggers a 'just use X' fight: Redis, DuckDB, or vector DBs

TLDR: A dev explored how to search 3 billion meaning-vectors and sparked a tooling brawl. Comments split between “read it once if it’s one-off,” “build an index or use a vector database,” and Redis loyalists saying it’s already solved—real talk for anyone building AI search at scale.

A dev tried to figure out how to search through 3 billion “vectors” (think: lists of numbers that capture meaning), got nerd‑sniped by a mention from Jeff Dean, and quickly learned the internet has Opinions. The first attempt crawled; a vectorized version ran faster; the MapReduce dream lingered. But the comments? Absolute fireworks.

One camp says: if it’s a one‑off search, just read the data once and move on. User sdenton4 swears by a simple pass over the files, and if you do this a lot, build an index for ANN (approximate nearest neighbor) or try usearch. Cue the “keep it simple” crowd cheering. Then Redis legend antirez storms in like “you’ll all rediscover Redis in two years” and claims vector sets are the new Streams—translation: for smallish jobs, just shove it in Redis and ship it. Meanwhile, drive‑by pragmatists lob “why not DuckDB?” and the toolbelt brigade yells “just use LanceDB or Turbopuffer” and be done.

Jokes flew about “3 billion vectors on a MacBook” with fans spinning like helicopter blades. The meme energy: “Just Use X” vs “Roll Your Own.” Underneath the snark, a real split: sequential read for quick jobs, indexes and vector databases when you scale, and Redis fans insisting it’s all already solved—if you’d only look.

Key Points

  • The author explores querying up to 3 billion vectors, inspired by an exchange with Jeff Dean and an alluded map-reduce approach.
  • They define the task: compute dot-product similarity between ~1,000 queries and a large document vector set stored as .npy files.
  • A small-scale test uses 3,000 document vectors (768-dimensional) to validate feasibility before scaling.
  • A naive nested-loop NumPy implementation computes 3 million dot products in about 1.99 seconds on an M2 MacBook.
  • Vectorizing the NumPy computation yields a much faster approach (details not shown in the excerpt).

Hottest takes

"Depending on how 'one-off' the query is, sequential read is the right answer." — sdenton4
"people realize there is something new is Redis in 2 years or more." — antirez
"Or just use a vector store like LanceDB or Turbopuffer and be done with it." — ta9000
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.