// the find
epsilla-cloud/vectordb
A high performance Vector Database leveraging parallel graph computing
Epsilla is a vector database with a C++ core that uses a custom graph index (NSG - navigating spreading-out graph) instead of the usual HNSW, wrapped in a real table/schema model with metadata filtering and hybrid search. Aimed at teams who want a self-hosted vector store with more SQL-like semantics than a bare FAISS/HNSWlib wrapper, with Python/JS/Ruby clients and a Docker-first workflow.
The index is actually implemented from scratch (nsg.cpp/hpp, nndescent for graph construction) rather than being another HNSWlib wrapper, which is a real differentiator among OSS vector DBs. SIMD distance kernels are split out per architecture (simdlib_avx2.hpp, simdlib_neon.hpp, transpose-avx2-inl.hpp), which shows actual low-level performance work instead of just claiming speed. It models tables/fields/primary keys properly, so metadata filtering and hybrid dense+sparse search are first-class instead of bolted on. There's a write-ahead log (write_ahead_log.hpp) for durability, which a lot of young vector DBs skip.
The headline '10x faster than HNSW' claim in the README has no linked benchmark, methodology, or reproducible numbers anywhere in the tree - take it on faith or not at all. Test coverage looks thin: a handful of standalone Python scripts (test.py, concurrent_test.py, gist-960-euclidean.py) rather than a real unit/integration suite for a hand-rolled index and WAL, which is exactly the kind of code that needs heavy testing. 'Cloud native, compute-storage separation, serverless, multi-tenancy' is marketing copy in the README that isn't backed by anything visible in this OSS tree - that's almost certainly gated behind Epsilla Cloud, so don't expect it from the self-hosted build. Dependencies like rapidjson and nlohmann/json are vendored directly into the repo instead of pulled via a package manager, which makes security patching and version bumps manual chores.