351 stars · MIT · v0.4.4 (2026-04-14) · Track this in Scout
One interface over several nearest-neighbour backends — the throwaway in-memory index for a single conversation.
▶Repo detailsthe review · specs · pros & cons
What it is
A tiny Python library giving one interface over several nearest-neighbour backends (exact search, HNSW, FAISS, Annoy and others), with save and load built in. It is from MinishLab, the team behind model2vec.
What it is good for. pgvector (Ed. 2 #11) is the right answer for vectors that must persist, be shared and be backed up. It is the wrong answer for a document a user uploaded four minutes ago and may delete in six: a per-import index, built in memory, queried a hundred times while they explore the map, then discarded, does not want a table, a migration or an HNSW build on a small VPS. It is also a way to settle Edition 3's open question — BERTopic versus turftopic versus LightRAG — because comparing embedding models over the same conversation ten times is trivial when the index is a variable and awkward when it is a database. Same team as model2vec, so the two compose without thought.
- Swapping backends is one argument, which turns "is HNSW worth it at our size" from an afternoon into a minute.
- No server, no schema, no migration. It is a Python object.
- Save and load to disk or Hugging Face, so an expensive index for a large permanent corpus can be cached rather than rebuilt.
- It genuinely overlaps pgvector, and running both without a clear rule about which owns what is how a codebase gets confusing. Write the rule down: persistent and shared goes in PostgreSQL, ephemeral and per-import goes here.
- In-memory means RAM. A large conversation is fine; a hundred concurrent users each holding an index is not, on one small server.
- 350 stars and a small team. Low risk because the interface is thin and the backends underneath are the well-known libraries — but it is a convenience layer, not infrastructure.
