About
Most teams bolt a vector database to a graph database and then spend their lives keeping the two in sync. Two systems, two copies of the data, two failure modes, and a layer of glue code in between that is always a little out of date. SwarnDB removes the seam. It is a production-grade engine, written in Rust, where a vector and a graph node are the same object: one identity, one storage path, one crash-recovery path. So a single query can move between what is similar and what is connected without ever leaving the engine. And if all you want is a fast, accurate vector store, that is exactly what you get out of the box. When you do want the graph, it is a real, typed graph: directed, typed edges that carry confidence and provenance, which you create explicitly or have an LLM extract. It is not a similarity graph inferred from your vectors. It is opt-in, per collection, ready the moment your problem grows past nearest-neighbor. In SwarnDB, the id of a vector is the id of its graph node. There is no foreign key, no mirror table, no eventual consistency between two stores. The thing you searched for and the thing you traverse from are literally the same row. Sharing identity is about the node, not the edges: the edges are explicit and typed, the ones you write with put_edge or extract with an LLM, never inferred from similarity. That single decision is what makes a query like this possible: scope by structure, then rank by meaning, in one plan. ~0.99 recall@10 at over 2,200 QPS, single host. Open Source!
Community Reviews
0 reviews
No reviews yet — be the first to share your experience.
No reviews yet. Be the first to share your thoughts.
