Building a high-performance Vector Database in Rust: My journey with FerresDB
For the past few months, I’ve been heads-down building FerresDB, a vector search engine designed for performance, reliability, and—most importantly—developer experience.
Why another vector database? Most options out there felt like "black boxes." You send a vector, you get a result, but you don't really see what's happening under the hood. I wanted to build something that combined the raw speed of Rust with a native visual experience.
The Tech Stack:
Core: Written in Rust for sub-millisecond search performance.
Algorithm: Using HNSW for efficient ANN (Approximate Nearest Neighbor) search.
Persistence: I implemented a Write-Ahead Log (WAL) and periodic snapshots to ensure data integrity and crash recovery.
Communication: REST APIs for simplicity, gRPC for low-latency production needs, and WebSockets for real-time monitoring.
The UI: A built-in Dashboard made with React/Tailwind to manage collections and test queries visually.
The "Indie" Challenge: Building a database from scratch is a massive undertaking. Ensuring thread-safety, atomic writes, and efficient memory management in Rust has been a steep but rewarding learning curve.
Current Status: The project is evolving daily. It’s already functional for development and testing (you can spin it up via Docker), and I’m preparing to make it fully open-source very soon.
Really cool to see someone tackling the developer experience gap in vector databases. Most existing options feel like you're just throwing vectors into a void and hoping the results make sense. The built-in dashboard for visual query testing is a smart differentiator — when I'm evaluating infrastructure tools, being able to actually see what's happening under the hood saves hours of debugging. The Rust + HNSW combination should give you serious performance headroom too. Are you planning to offer a hosted/managed version eventually, or keeping it strictly self-hosted?
Building a vector DB from scratch in Rust is no joke — the concurrency and memory safety challenges alone make this a serious technical undertaking. The HNSW + native pre-filtering combo is smart since most vector DBs treat filtering as an afterthought and just post-filter results, which kills precision at low k values.
The MCP integration for Claude Desktop is a really interesting distribution angle too. That's where a lot of devs are spending time right now and having native vector search there could drive organic adoption.
What's your target use case — more RAG/embedding search or real-time recommendation systems? The WAL + snapshot approach suggests you're optimizing for durability which leans more production/enterprise. Curious how it benchmarks against something like Qdrant on the HNSW search side.
Congratulations on your launch. It looks impressive! What channels are you exploring to attract early users?