A compact vector search engine
USearch is an approximate-nearest-neighbor (ANN) engine for vector and similarity search, written as a small, single-header C++ library with SIMD acceleration. Its whole pitch is being a lighter, more portable alternative to FAISS: a tiny codebase, no heavy dependencies, and native bindings across many languages (Python, JavaScript, Rust, Go, Java, Swift, C#, and more), plus the ability to run in the browser via WebAssembly. At 4,167 stars as of 2026-06, it is the go-to when you want embedded vector search without pulling in a large library or standing up a database.
The mental model: USearch is an embeddable engine you call in-process, not a vector database you run as a service.
What it does
You build an index, add vectors with ids, and search for nearest neighbors, the same HNSW-based core that FAISS uses. What sets USearch apart is the surrounding design: arbitrary custom distance metrics (not a fixed list), several quantization options (including bf16, f16, and int8) to trade precision for memory and speed, flexible filtering with predicate functions, and streaming serialization so you can search an index from disk without loading it entirely into RAM. The project reports substantial speed and size advantages over FAISS in its benchmarks; treat those as the maintainer’s published numbers and benchmark for your own workload.
Install
pip install usearchnpm install usearchIt is also available for Rust, Go, Swift, C#, and as a single C++ header. The same on-disk index can be reused across these language bindings, which is part of the appeal for polyglot stacks.
USearch versus FAISS
This is the comparison the project invites, so be precise about it. Both use an HNSW graph at the core, so the algorithmic quality is comparable. The difference is philosophy: FAISS is the feature-rich, batch-oriented library from Meta with a large surface and BLAS dependencies; USearch is small, dependency-light, multi-language, and portable down to the browser and edge. Choose FAISS when you want its full feature set and ecosystem for large offline batch work; choose USearch when size, portability, multi-language access, or custom metrics matter more. They are not far apart on accuracy; they differ on packaging and reach.
Where it fits, and where it doesn’t
USearch is a strong fit when you want embedded ANN search inside an application, when you need the same index usable from several languages, when custom distance metrics (geospatial, molecular, your own) are required, or when you must run on constrained targets like the browser or edge devices.
It is not a replacement for a full vector database. It has no remote API, no built-in distributed mode, and no ACID guarantees, so for online, multi-node, hybrid-filtered serving you want a system like Qdrant or Pinecone, possibly with USearch embedded inside it. Concurrency also has limits: concurrent adds and searches are supported, but concurrent removal has been a weak spot, so design around that. And feature parity across language bindings is uneven, with custom metrics and some features richer in C++, Python, and Rust than in others.
USearch versus the alternatives
| USearch | FAISS | full vector DB (Qdrant, Pinecone) | |
|---|---|---|---|
| Form | embeddable library | embeddable library | standalone service |
| Footprint | tiny, no heavy deps | larger, BLAS dependencies | service to operate |
| Languages | many native bindings | mainly C++ and Python | SDKs over an API |
| Custom metrics | arbitrary | a fixed set | limited |
| Best for | embedded, portable, polyglot | feature-rich offline batch | online, distributed serving |
Counts where shown are from GitHub as of June 2026. FAISS is the feature-rich incumbent for large-scale offline work. A full vector database adds a service, an API, distribution, and ACID guarantees that a library does not. USearch’s distinct value is being the small, portable, multi-language engine you embed, which is why projects like a memory layer or an analytical database integrate it rather than reimplement ANN.
The star curve
The star curve reflects steady growth as an embeddable engine adopted inside other systems (analytical databases, memory layers, and search features) rather than a consumer-facing spike. The active release cadence, with versions every few weeks, points to ongoing development.
What the issue tracker warns you about
The recurring issues are about edges, not the core. Feature parity across language bindings is uneven, so a capability you used in Python may be missing in Java or JavaScript. Concurrent removal has had design issues that a planned major version aims to fix, so avoid mixing concurrent adds and removes. Quantization trades precision for speed and memory, and validating the accuracy impact for your data is on you. And serialization and persistence behavior, while supported, has nuances worth testing before relying on them in production.
Related
For a memory layer that uses a vector store underneath, see Mem0. For document parsing ahead of embedding, see docling and unstructured. For the AI SDK to build retrieval apps, see vercel/ai. For what is trending, see LLM tooling, the daily digest, and the weekly report.
FAQ
USearch vs FAISS, which should I use? Both use HNSW at the core, so accuracy is comparable. FAISS is feature-rich and batch-oriented with BLAS dependencies. USearch is small, dependency-light, multi-language, and portable to the browser and edge. Choose FAISS for its full feature set, USearch for size, portability, and custom metrics.
Can USearch replace a vector database like Qdrant or Pinecone? No. USearch is an embeddable library with no remote API, distribution, or ACID guarantees. A vector database provides those as a service. You can, however, embed USearch inside a larger system that provides them.
Does USearch work across multiple languages? Yes. It has native bindings for Python, JavaScript, Rust, Go, Java, Swift, C#, and more, and the same on-disk index is reusable across them. Note that feature parity is uneven, with custom metrics and some features richer in C++, Python, and Rust.
Does quantization hurt accuracy? It trades precision for memory and speed. Options like bf16 keep accuracy close to full precision, while int8 saves more at a larger accuracy cost. Validate the impact on your own data, since there is no automatic accuracy guarantee.
Can USearch run in the browser or on edge devices? Yes. It supports WebAssembly for the browser and has bindings suited to mobile and edge, and streaming serialization lets you search an index from disk without loading it fully into memory.