Hey HN, we want to share HelixDB helix db, a project my team and I are working on. It is a native graph-vector database built specifically to solve the 'who' in RAG by mapping expertise and organizational relationships natively.

Why a hybrid? Vector databases are useful for similarity queries, but many AI-driven applications need both similarity and relationship queries. When you chunk corporate data for simple vector search, you destroy the relational context—like reporting lines or project history—that is essential for accurate expert identification. We solved this by combining approximate vector search and BM25 full-text search with property graphs in one engine.

Here are some ways teams are using this today:

• Expert Discovery: Instead of searching for 'how to fix Java bugs,' you can query for 'engineers with three years of experience in our payment service who have resolved similar tickets.'
• Talent Mapping: Automatically link new project commits to internal contributors, allowing your AI to identify which teams are currently overwhelmed versus those with capacity.
• Incident Response: Instantly map a failed service component back to the original author and current maintenance team by traversing the graph, rather than just returning documentation.

Many people are skeptical of 'yet another database' and the complexity of managing two systems, but we went ahead and did it anyway because stitching together a separate graph DB and a vector store introduces significant latency and synchronization nightmares. We built our own LSM-based storage engine in Rust to unify these paradigms, which simplifies your stack significantly. You can read more about our architecture here: introduction.

Regarding performance, our benchmarking shows that we are on par with Pinecone and Qdrant for vector throughput, and our graph traversal is up to 100x faster than Neo4j for deep multi-hop queries.

If you’d like to try it out in a simple RAG demo, you can follow this guide: examples. Many thanks! Comments and feedback welcome!