Hey HN, we want to share HelixDB, a project we’ve been building to solve the scaling crisis in AI infrastructure. Why a hybrid? Vector databases are useful for similarity queries, but many AI-driven applications need both similarity and relationship queries to be accurate. Our native Graph-Vector database allows you to run both without the cost of managing two separate systems, as detailed in our architecture overview: https://docs.helix-db.com/architecture.

Why HelixDB?

• Reducing infrastructure spend: By moving from memory-heavy stores to an object-storage-backed architecture, you avoid the scaling costs that hit when your corpus grows to millions of documents.
• Streamlining RAG pipelines: Unifying graph and vector types allows for complex multi-hop reasoning in a single query, which you can see in our performance comparison: https://docs.helix-db.com/benchmarks.
• High-performance retrieval: Our Rust-native engine ensures low-latency reads via intelligent caching, optimizing throughput for high-concurrency environments.

Technical Deep Dive

Many people are skeptical of “yet another database,” but we built a custom LSM-based engine because existing solutions struggle with efficient object storage integration. By decoupling storage from compute, we can keep costs at commodity rates while providing sub-millisecond retrieval. Benchmarking shows we are on par with Pinecone and Qdrant for vector similarity, while our graph traversal engine is up to three orders of magnitude faster than Neo4j for massive, multi-hop RAG queries. You can view our full performance report and methodology here: https://github.com/HelixDB/benchmark-results.

If you’d like to try it out in a simple RAG demo, you can follow this guide: https://github.com/HelixDB/rag-demo. Many thanks! Comments and feedback are very welcome!