351 stars · MIT · v0.4.4 (2026-04-14) · Track this in Rising ↗
One interface over several nearest-neighbour backends — the throwaway in-memory index for a single conversation.
Radar check
What we found when we opened it. Every bar is one fact, with its date.
Last code pushed 5 Oct 2026, 22 days before this check.
Latest release v0.4.6 on 26 Sep 2026.
Public since November 2024, a little over 1 year.
352 stars and 15 forks.
3 commits and 2 new issues in the last 90 days.
4 contributors. 3 pull requests merged in 90 days. A small team carries it.
No security policy file says how to report a problem. No published security advisories.
How the bars are scored
- Alive. Days since the last code push: a week or less 100, a month 90, three months 70, six months 50, a year 30, eighteen months 15, older 0.
- Releases. Age of the latest GitHub release, on a similar scale; no bar when the project publishes no releases.
- Maturity. Age of the project: eight years 100, five 90, three 70, two 55, one 40, six months 25, younger 10.
- Adoption. Stars on a log scale: 100,000 stars is 100, 10,000 is 80, 1,000 is 60, 100 is 40.
- Activity. Commits in the last 90 days: 300 or more 100, 100 85, 30 65, 10 45, any 25.
- Community. People who have contributed: 100 or more 100, 30 80, 10 60, 5 40, 2 25, one 10.
- Security. A published security policy 80, none 40; published advisories are listed, not scored.
Checked by Repo Radar on 25 Oct 2026 from the repository on GitHub. Covered in Edition 8.
▶Repo detailsthe review · specs · pros & cons · install
What it does
You give it a set of vectors, which are lists of numbers representing items, and it builds an index you can query for the closest matches. It wraps several well-known methods behind one interface, including exact search, HNSW, FAISS, Annoy and others, so changing method is one argument rather than a rewrite. The index can be saved to disk or to Hugging Face and loaded again, so an expensive build can be cached. It also supports deleting and inserting items after the index is built. Version 0.4.4 was published on 14 April 2026 and code was last pushed in May 2026. It is a thin convenience layer, not a database: it stores nothing permanently and offers no server, no schema and no access control.
Why it matters
Who it suits. Developers who need similarity search over data that only exists for a short time, such as a document someone uploaded a few minutes ago. It also suits anyone comparing embedding models, because swapping the method or the model is trivial when the index is just an object. Skip it if the vectors must persist, be shared between machines, or be backed up, because that is what a database is for.
Verdict. Useful and small, with one real risk: it overlaps a vector database closely enough that a project can end up running both without a rule about which owns what. Write that rule down before adopting it. Memory is the other limit, since every index lives in RAM and many concurrent users each holding one will not fit on a small machine. FAISS is the heavyweight library underneath several of its backends, and hnswlib is the smaller one most people reach for directly.
Summary (Key Points)from the README
Key features
- Unified interface: One API across all supported backends, so different indexing methods and distance metrics can be swapped without learning a new package.
- Lightweight: Described as a light-weight, low-dependency vector store with minimal dependencies and fast performance.
- Many backends: Supports BASIC, HNSW, USEARCH, ANNOY, PYNNDESCENT, FAISS (with nine index types), and VOYAGER.
- Serialization: Save and load vector stores for persistence.
- Hugging Face Hub integration: Push vector stores to and load them from the Hugging Face Hub, optionally storing the embedding model name in metadata (for example, "minishlab/potion-base-8M").
- Backend evaluation: Measure queries per second and recall to compare backends.
- Tunable parameters: Each backend exposes parameters such as metric, number of trees, ef_construction, and m, with documented defaults.
Important
- Deletion limits: ANN backends do not support dynamic deletion; removing items requires recreating the index.
- Insertion support: Only FAISS, HNSW, Usearch and the BASIC backend allow insertion, and BASIC is the only one that also supports deletion.
- Metric restrictions: Each backend supports a different set of metrics. USEARCH's hamming and tanimoto metrics require uint8 vectors bit-packed with np.packbits.
- Optional installs: Backends and integrations are installed separately, so you must add the ones you need.
Written by an AI model from the project’s README; not part of the review, and it can be wrong.
- Changing the search method is one argument, which turns a day of work into a minute.
- No server, no schema and no migration. The index is an ordinary Python object.
- Save and load means an expensive index for a stable collection can be built once.
- It overlaps a vector database, and running both without a clear rule gets confusing.
- Everything lives in memory, so many concurrent indexes will not fit on a small machine.
- At 350 stars it is a small project. The risk is low because the backends are well known, but it is a convenience layer rather than infrastructure.
pip install vicinity
