HelixDB – Native graph and vector types for RAG and retrieval
Hey HN! We're college friends building HelixDB. It's a database that natively supports both graph and vector types. It’s designed for AI-driven apps like RAG, vector search, code indexing, and agent frameworks where you need both explicit relationships and similarity. We came up with the idea for Helix at university, while building a graph database as a side project in Rust. Reading some research papers on RAG setups, I realised there was a lot of infrastructure setup to get started. You need your own server, a graph database, a vector database and then some bespoke middleman software to…
In plain words
HelixDB is a database built in Rust that combines graph and vector capabilities in a single system. It targets developers building AI applications such as retrieval-augmented generation (RAG), vector search, code indexing, and agent frameworks that require both explicit relationship mapping and similarity matching. Rather than requiring separate graph and vector databases with middleware to connect them, HelixDB consolidates these functions natively, simplifying infrastructure setup for AI-driven applications.
written from the facts on this page · September 2026
From the sources
In the maker’s words, at launch
Hey HN! We're college friends building HelixDB. It's a database that natively supports both graph and vector types. It’s designed for AI-driven apps like RAG, vector search, code indexing, and agent frameworks where you need both explicit relationships and similarity. We came up with the idea for Helix at university, while building a graph database as a side project in Rust. Reading some research papers on RAG setups, I realised there was a lot of infrastructure setup to get started. You need your own server, a graph database, a vector database and then some bespoke middleman software to link them together. After looking into how vectors work I discovered you can (kind of) abstract it into a graph. The vectors are just nodes with coordinates! And edges represent neighbour links. I realised I could link this up to the current graph infrastructure, allowing traversals in conjunction with similarity searches. The way Helix works, from a low level, is you have four main types in respective tables. You have graph nodes, graph edges, vector nodes, and vector edges. The vector edges are irrelevant to developers (they just store the neighbour link for the similarity algorithm). The vector nodes work in the same way you'd use vectors in Pinecone or Qdrant by utilising HNSW. Likewise, the graph nodes work the same as they would in Neo4J or Neptune. The graph edges, however, are where things get interesting; you are able to define relationships between graph nodes, but also vectors, meaning you can have explicit dependencies between vectors and nodes or vice versa. So, you can run a similarity search, then walk the graph to get more structured context. Or the other way around. When you run Helix, it spins up as its own server (like a Docker container). To query it, you hit an auto-generated API endpoint. Out of ignorance, I used to think databases compiled their queries and ran them like functions — like in normal programming. Turns out they don’t, and I never understood why that wasn’t the norm. So, like with what SpaceTimeDB is doing, we made Helix queries deployable. You write a query, and it gets built directly into the database as its own endpoint. This avoids the overhead of sending entire query strings over the network and cuts latency down a lot (and also prevents injections). Over the past week we've expanded our query language, released vector types, and two SDKs (Python & TypeScript), making it easy to insert and query data. HelixDB is open source, super easy to self-host, and we offer a managed service. If you're building anything involving retrieval, we’d love your feedback!
More ai this month
the category →
I trained a 125M-parameter transformer to autocomplete piano performances in real time (~108 notes/sec on an iPhone 15). The idea is basically GitHub Copilot or Tabnine, except instead of prompting it with code, you prompt it by playing a few notes on a MIDI piano. The model then continues what you played, entirely on-device. The app is free if anyone wants to try it. Happy to answer questions about the model, training, Core ML, or the many things that didn't work.
AI · 17d ago · simedw.com
Astute▲585Automate your B2B brand going viral, with new media creators
AI · 18d ago · company-app.joinastute.com
Hey HN, Henry from Cactus here! We previously released Cactus Needle, a 14MB agentic LLM for tool call, device use, and structured extraction for phones, wearables, smart homes, small robots and microcontrollers. We got really great feedback here, and have now incorporated the suggestions to release Needle 2. The whole model is a single 14MB binary that runs a full session in 28MB of RAM; 45m parameters at 2bit compression. Needle hits 500 tokens/sec decode speed on a Raspberry Pi 5, sits between 400-1,500 tokens/sec on VR devices like Meta Quest 3S and Apple Vision Pro, and ranges…
AI · 26d ago · cactuscompute.com
Launched alongside, April 2025
the whole month →- IB
Hi everyone, I built PyXL — a hardware processor that executes a custom assembly generated from Python programs, without using a traditional interpreter or virtual machine. It compiles Python -> CPython Bytecode -> Instruction set designed for direct hardware execution. I’m sharing an early benchmark: a GPIO test where PyXL achieves a 480ns round-trip toggle — compared to 14-25 micro seconds on a MicroPython Pyboard - even though PyXL runs at a lower clock (100MHz vs. 168MHz). The design is stack-based, fully pipelined, and preserves Python's dynamic typing without static type restrictions.…
Dev tools · 2025 · runpyxl.com
- UC
Life & fun · 2025 · filiph.github.io
- IB
https://the-pocket.github.io/Tutorial-Codebase-Knowledge/
AI · 2025 · github.com
