The best Hacker News stories from Show from the past day

from

All Show

from the past*

day week month

with these search terms:

Create follow Go back

Latest posts:

Show HN: I’ve built an IoT device to let my family know when I’m in a meeting

Show HN: I’ve built an IoT device to let my family know when I’m in a meeting

Show HN: Lumier – Run macOS VMs in a Docker

Hey HN, we're excited to share Lumier (<a href="https://github.com/trycua/cua/tree/main/libs/lumier">https://github.com/trycua/cua/tree/main/libs/lumier</a>), an open-source tool for running macOS and Linux virtual machines in Docker containers on Apple Silicon Macs.<p>When building virtualized environments for AI agents, we needed a reproducible way to package and distribute macOS VMs. Inspired by projects like dockur/windows (<a href="https://github.com/dockur/windows">https://github.com/dockur/windows</a>) that pioneered running Windows in Docker, we wanted to create something similar but optimized for Apple Silicon. The existing solutions either didn't support M-series chips or relied on KVM/Intel emulation, which was slow and cumbersome. We realized we could leverage Apple's Virtualization Framework to create a much better experience.<p>Lumier takes a different approach: it uses Docker as a delivery mechanism (not for isolation) and connects to a lightweight virtualization service (lume) running on your Mac. This creates true hardware-accelerated VMs using Apple's native virtualization capabilities.<p>With Lumier, you can: - Launch a ready-to-use macOS VM in minutes with zero manual setup - Access your VM through any web browser via VNC - Share files between your host and VM effortlessly - Use persistent storage or ephemeral mode for quick tests - Automate VM startup with custom scripts<p>All of this works natively on Apple Silicon (M1/M2/M3/M4) - no emulation required.<p>To get started:<p>1. Install Docker for Apple Silicon: <a href="https://desktop.docker.com/mac/main/arm64/Docker.dmg" rel="nofollow">https://desktop.docker.com/mac/main/arm64/Docker.dmg</a><p>2. Install lume background service with our one-liner:<p><pre><code> /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/lume/scripts/install.sh)" </code></pre> 3. Start a VM (ephemeral mode):<p><pre><code> docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -e VM_NAME=lumier-vm \ -e VERSION=ghcr.io/trycua/macos-sequoia-cua:latest \ -e CPU_CORES=4 \ -e RAM_SIZE=8192 \ trycua/lumier:latest </code></pre> 4. Open <a href="http://localhost:8006/vnc.html" rel="nofollow">http://localhost:8006/vnc.html</a> in your browser. The container will generate a unique password for each VM instance - you'll see it in the container logs.<p>For persistent storage (so your changes survive container restarts):<p>mkdir -p storage docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -v $(pwd)/storage:/storage \ -e VM_NAME=lumier-vm \ -e HOST_STORAGE_PATH=$(pwd)/storage \ trycua/lumier:latest<p>Want to share files with your VM? Just add another volume:<p>mkdir -p shared docker run ... -v $(pwd)/shared:/shared -e HOST_SHARED_PATH=$(pwd)/shared ...<p>You can even automate VM startup by placing an on-logon.sh script in shared/lifecycle/.<p>We're seeing people use Lumier for: - Development and testing environments that need macOS - CI/CD pipelines for Apple platform apps - Disposable macOS instances for security research - Automated UI testing across macOS versions - Running AI agents in isolated environments<p>Lumier is 100% open-source under the MIT license. We're actively developing it as part of our work on C/ua (<a href="https://github.com/trycua/cua">https://github.com/trycua/cua</a>), and we'd love your feedback, bug reports, or feature ideas.<p>We'll be here to answer any technical questions and look forward to your comments!

Show HN: Lumier – Run macOS VMs in a Docker

Hey HN, we're excited to share Lumier (<a href="https://github.com/trycua/cua/tree/main/libs/lumier">https://github.com/trycua/cua/tree/main/libs/lumier</a>), an open-source tool for running macOS and Linux virtual machines in Docker containers on Apple Silicon Macs.<p>When building virtualized environments for AI agents, we needed a reproducible way to package and distribute macOS VMs. Inspired by projects like dockur/windows (<a href="https://github.com/dockur/windows">https://github.com/dockur/windows</a>) that pioneered running Windows in Docker, we wanted to create something similar but optimized for Apple Silicon. The existing solutions either didn't support M-series chips or relied on KVM/Intel emulation, which was slow and cumbersome. We realized we could leverage Apple's Virtualization Framework to create a much better experience.<p>Lumier takes a different approach: it uses Docker as a delivery mechanism (not for isolation) and connects to a lightweight virtualization service (lume) running on your Mac. This creates true hardware-accelerated VMs using Apple's native virtualization capabilities.<p>With Lumier, you can: - Launch a ready-to-use macOS VM in minutes with zero manual setup - Access your VM through any web browser via VNC - Share files between your host and VM effortlessly - Use persistent storage or ephemeral mode for quick tests - Automate VM startup with custom scripts<p>All of this works natively on Apple Silicon (M1/M2/M3/M4) - no emulation required.<p>To get started:<p>1. Install Docker for Apple Silicon: <a href="https://desktop.docker.com/mac/main/arm64/Docker.dmg" rel="nofollow">https://desktop.docker.com/mac/main/arm64/Docker.dmg</a><p>2. Install lume background service with our one-liner:<p><pre><code> /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/lume/scripts/install.sh)" </code></pre> 3. Start a VM (ephemeral mode):<p><pre><code> docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -e VM_NAME=lumier-vm \ -e VERSION=ghcr.io/trycua/macos-sequoia-cua:latest \ -e CPU_CORES=4 \ -e RAM_SIZE=8192 \ trycua/lumier:latest </code></pre> 4. Open <a href="http://localhost:8006/vnc.html" rel="nofollow">http://localhost:8006/vnc.html</a> in your browser. The container will generate a unique password for each VM instance - you'll see it in the container logs.<p>For persistent storage (so your changes survive container restarts):<p>mkdir -p storage docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -v $(pwd)/storage:/storage \ -e VM_NAME=lumier-vm \ -e HOST_STORAGE_PATH=$(pwd)/storage \ trycua/lumier:latest<p>Want to share files with your VM? Just add another volume:<p>mkdir -p shared docker run ... -v $(pwd)/shared:/shared -e HOST_SHARED_PATH=$(pwd)/shared ...<p>You can even automate VM startup by placing an on-logon.sh script in shared/lifecycle/.<p>We're seeing people use Lumier for: - Development and testing environments that need macOS - CI/CD pipelines for Apple platform apps - Disposable macOS instances for security research - Automated UI testing across macOS versions - Running AI agents in isolated environments<p>Lumier is 100% open-source under the MIT license. We're actively developing it as part of our work on C/ua (<a href="https://github.com/trycua/cua">https://github.com/trycua/cua</a>), and we'd love your feedback, bug reports, or feature ideas.<p>We'll be here to answer any technical questions and look forward to your comments!

Show HN: Muscle-Mem, a behavior cache for AI agents

Hi HN! Erik here from Pig.dev, and today I'd like to share a new project we've just open sourced:<p>Muscle Mem is an SDK that records your agent's tool-calling patterns as it solves tasks, and will deterministically replay those learned trajectories whenever the task is encountered again, falling back to agent mode if edge cases are detected. Like a JIT compiler, for behaviors.<p>At Pig, we built computer-use agents for automating legacy Windows applications (healthcare, lending, manufacturing, etc).<p>A recurring theme we ran into was that businesses <i>already</i> had RPA (pure-software scripts), and it worked for them in most cases. The pull to agents as an RPA alternative was <i>not</i> to have an infinitely flexible "AI Employees" as tech Twitter/X may want you to think, but simply because their RPA breaks under occasional edge-cases and agents can gracefully handle those cases.<p>Using a pure-agent approach proved to be highly wasteful. Window's accessibility APIs are poor, so you're generally stuck using pure-vision agents, which can run around $40/hr in token costs and take 5x longer than a human to perform a workflow. At this point, you're better off hiring a human.<p>The goal of Muscle-Mem is to get LLMs out of the hot path of repetitive automations, intelligently swapping between script-based execution for repeat cases, and agent-based automations for discovery and self-healing.<p>While inspired by computer-use environments, Muscle Mem is designed to generalize to any automation performing discrete tasks in dynamic environments. It took a great deal of thought to figure out an API that generalizes, which I cover more deeply in this blog: <a href="https://erikdunteman.com/blog/muscle-mem/" rel="nofollow">https://erikdunteman.com/blog/muscle-mem/</a><p>Check out the repo, consider giving it a star, or dive deeper into the above blog. I look forward to your feedback!

Show HN: Muscle-Mem, a behavior cache for AI agents

Hi HN! Erik here from Pig.dev, and today I'd like to share a new project we've just open sourced:<p>Muscle Mem is an SDK that records your agent's tool-calling patterns as it solves tasks, and will deterministically replay those learned trajectories whenever the task is encountered again, falling back to agent mode if edge cases are detected. Like a JIT compiler, for behaviors.<p>At Pig, we built computer-use agents for automating legacy Windows applications (healthcare, lending, manufacturing, etc).<p>A recurring theme we ran into was that businesses <i>already</i> had RPA (pure-software scripts), and it worked for them in most cases. The pull to agents as an RPA alternative was <i>not</i> to have an infinitely flexible "AI Employees" as tech Twitter/X may want you to think, but simply because their RPA breaks under occasional edge-cases and agents can gracefully handle those cases.<p>Using a pure-agent approach proved to be highly wasteful. Window's accessibility APIs are poor, so you're generally stuck using pure-vision agents, which can run around $40/hr in token costs and take 5x longer than a human to perform a workflow. At this point, you're better off hiring a human.<p>The goal of Muscle-Mem is to get LLMs out of the hot path of repetitive automations, intelligently swapping between script-based execution for repeat cases, and agent-based automations for discovery and self-healing.<p>While inspired by computer-use environments, Muscle Mem is designed to generalize to any automation performing discrete tasks in dynamic environments. It took a great deal of thought to figure out an API that generalizes, which I cover more deeply in this blog: <a href="https://erikdunteman.com/blog/muscle-mem/" rel="nofollow">https://erikdunteman.com/blog/muscle-mem/</a><p>Check out the repo, consider giving it a star, or dive deeper into the above blog. I look forward to your feedback!

Show HN: Muscle-Mem, a behavior cache for AI agents

Hi HN! Erik here from Pig.dev, and today I'd like to share a new project we've just open sourced:<p>Muscle Mem is an SDK that records your agent's tool-calling patterns as it solves tasks, and will deterministically replay those learned trajectories whenever the task is encountered again, falling back to agent mode if edge cases are detected. Like a JIT compiler, for behaviors.<p>At Pig, we built computer-use agents for automating legacy Windows applications (healthcare, lending, manufacturing, etc).<p>A recurring theme we ran into was that businesses <i>already</i> had RPA (pure-software scripts), and it worked for them in most cases. The pull to agents as an RPA alternative was <i>not</i> to have an infinitely flexible "AI Employees" as tech Twitter/X may want you to think, but simply because their RPA breaks under occasional edge-cases and agents can gracefully handle those cases.<p>Using a pure-agent approach proved to be highly wasteful. Window's accessibility APIs are poor, so you're generally stuck using pure-vision agents, which can run around $40/hr in token costs and take 5x longer than a human to perform a workflow. At this point, you're better off hiring a human.<p>The goal of Muscle-Mem is to get LLMs out of the hot path of repetitive automations, intelligently swapping between script-based execution for repeat cases, and agent-based automations for discovery and self-healing.<p>While inspired by computer-use environments, Muscle Mem is designed to generalize to any automation performing discrete tasks in dynamic environments. It took a great deal of thought to figure out an API that generalizes, which I cover more deeply in this blog: <a href="https://erikdunteman.com/blog/muscle-mem/" rel="nofollow">https://erikdunteman.com/blog/muscle-mem/</a><p>Check out the repo, consider giving it a star, or dive deeper into the above blog. I look forward to your feedback!

Show HN: Muscle-Mem, a behavior cache for AI agents

Hi HN! Erik here from Pig.dev, and today I'd like to share a new project we've just open sourced:<p>Muscle Mem is an SDK that records your agent's tool-calling patterns as it solves tasks, and will deterministically replay those learned trajectories whenever the task is encountered again, falling back to agent mode if edge cases are detected. Like a JIT compiler, for behaviors.<p>At Pig, we built computer-use agents for automating legacy Windows applications (healthcare, lending, manufacturing, etc).<p>A recurring theme we ran into was that businesses <i>already</i> had RPA (pure-software scripts), and it worked for them in most cases. The pull to agents as an RPA alternative was <i>not</i> to have an infinitely flexible "AI Employees" as tech Twitter/X may want you to think, but simply because their RPA breaks under occasional edge-cases and agents can gracefully handle those cases.<p>Using a pure-agent approach proved to be highly wasteful. Window's accessibility APIs are poor, so you're generally stuck using pure-vision agents, which can run around $40/hr in token costs and take 5x longer than a human to perform a workflow. At this point, you're better off hiring a human.<p>The goal of Muscle-Mem is to get LLMs out of the hot path of repetitive automations, intelligently swapping between script-based execution for repeat cases, and agent-based automations for discovery and self-healing.<p>While inspired by computer-use environments, Muscle Mem is designed to generalize to any automation performing discrete tasks in dynamic environments. It took a great deal of thought to figure out an API that generalizes, which I cover more deeply in this blog: <a href="https://erikdunteman.com/blog/muscle-mem/" rel="nofollow">https://erikdunteman.com/blog/muscle-mem/</a><p>Check out the repo, consider giving it a star, or dive deeper into the above blog. I look forward to your feedback!

Show HN: Semantic Calculator (king-man+woman=?)

I've been playing with embeddings and wanted to try out what results the embedding layer will produce based on just word-by-word input and addition / subtraction, beyond what many videos / papers mention (like the obvious king-man+woman=queen). So I built something that doesn't just give the first answer, but ranks the matches based on distance / cosine symmetry. I polished it a bit so that others can try it out, too.<p>For now, I only have nouns (and some proper nouns) in the dataset, and pick the most common interpretation among the homographs. Also, it's case sensitive.

Show HN: Semantic Calculator (king-man+woman=?)

I've been playing with embeddings and wanted to try out what results the embedding layer will produce based on just word-by-word input and addition / subtraction, beyond what many videos / papers mention (like the obvious king-man+woman=queen). So I built something that doesn't just give the first answer, but ranks the matches based on distance / cosine symmetry. I polished it a bit so that others can try it out, too.<p>For now, I only have nouns (and some proper nouns) in the dataset, and pick the most common interpretation among the homographs. Also, it's case sensitive.

Show HN: The missing inbox for GitHub pull requests

Mergeable is an improved inbox for GitHub pull requests. They can be organized according to your rules into any number of sections, each section being defined as an arbitrary search query. Data is refreshed periodically, and is kept locally in the browser.<p>Mergeable is an open source project, which can be self-hosted very easily. A free public instance is also available to get started very quickly.

Show HN: AG-UI Protocol – Bring Agents into Frontend Applications

Show HN: A5

Show HN: A5

Show HN: A5

Show HN: Basecoat – shadcn/UI components, no React required

Basecoat ports the upcoming shadcn/ui v4 [1] to plain HTML + Tailwind (no React):<p>- Live demo & documentation: <a href="https://basecoatui.com" rel="nofollow">https://basecoatui.com</a><p>- MIT‑licensed and free: <a href="https://github.com/hunvreus/basecoat/">https://github.com/hunvreus/basecoat/</a><p>- Works with any backend (Flask, Django, Rails, PHP, etc.) or static site.<p>- Fully theme‑compatible with shadcn/ui [2].<p>- Uses a sliver of Alpine.js only for a few interactive bits (e.g. combobox). Swap in your own JS if you prefer.<p>- Dead simple to use, just drop in a class here and there:<p><pre><code> <button class="btn" data-tooltip="This is a tooltip text">Click me</button> </code></pre> Why I built it: after moving from a Next.js stack back to Flask + Tailwind + HTMX, I missed shadcn/ui and didn’t want walls of Tailwind classes (like Flowbite or Preline).<p>Feedback is most welcome: bugs, requests for components, criticism.<p>[1]: <a href="https://v4.shadcn.com/" rel="nofollow">https://v4.shadcn.com/</a><p>[2]: <a href="https://basecoatui.com/installation/#install-theming" rel="nofollow">https://basecoatui.com/installation/#install-theming</a><p>[3]: <a href="https://pagescms.org" rel="nofollow">https://pagescms.org</a>

Show HN: Basecoat – shadcn/UI components, no React required

Basecoat ports the upcoming shadcn/ui v4 [1] to plain HTML + Tailwind (no React):<p>- Live demo & documentation: <a href="https://basecoatui.com" rel="nofollow">https://basecoatui.com</a><p>- MIT‑licensed and free: <a href="https://github.com/hunvreus/basecoat/">https://github.com/hunvreus/basecoat/</a><p>- Works with any backend (Flask, Django, Rails, PHP, etc.) or static site.<p>- Fully theme‑compatible with shadcn/ui [2].<p>- Uses a sliver of Alpine.js only for a few interactive bits (e.g. combobox). Swap in your own JS if you prefer.<p>- Dead simple to use, just drop in a class here and there:<p><pre><code> <button class="btn" data-tooltip="This is a tooltip text">Click me</button> </code></pre> Why I built it: after moving from a Next.js stack back to Flask + Tailwind + HTMX, I missed shadcn/ui and didn’t want walls of Tailwind classes (like Flowbite or Preline).<p>Feedback is most welcome: bugs, requests for components, criticism.<p>[1]: <a href="https://v4.shadcn.com/" rel="nofollow">https://v4.shadcn.com/</a><p>[2]: <a href="https://basecoatui.com/installation/#install-theming" rel="nofollow">https://basecoatui.com/installation/#install-theming</a><p>[3]: <a href="https://pagescms.org" rel="nofollow">https://pagescms.org</a>

Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

Hey HN, we want to share HelixDB (<a href="https://github.com/HelixDB/helix-db/">https://github.com/HelixDB/helix-db/</a>), a project a college friend and I are working on. It’s a new database that natively intertwines graph and vector types, without sacrificing performance. It’s written in Rust and our initial focus is on supporting RAG. Here’s a video runthrough: <a href="https://screen.studio/share/szgQu3yq" rel="nofollow">https://screen.studio/share/szgQu3yq</a>.<p>Why a hybrid? Vector databases are useful for similarity queries, while graph databases are useful for relationship queries. Each stores data in a way that’s best for its main type of query (e.g. key-value stores vs. node-and-edge tables). However, many AI-driven applications need <i>both</i> similarity and relationship queries. For example, you might use vector-based semantic search to retrieve relevant legal documents, and then use graph traversal to identify relationships between cases.<p>Developers of such apps have the quandary of needing to build on top of two different databases—a vector one and a graph one—plus you have to link them together and sync the data. Even then, your two databases aren't designed to work together—for example, there’s no native way to perform joins or queries that span both systems. You’ll need to handle that logic at the application level.<p>Helix started when we realized that there are ways to integrate vector and graph data that are both fast and suitable for AI applications, especially RAG-based ones. See this cool research paper: <a href="https://arxiv.org/html/2408.04948v1" rel="nofollow">https://arxiv.org/html/2408.04948v1</a>. After reading that and some other papers on graph and hybrid RAG, we decided to build a hybrid DB. Our aim was to make something better to use from a developer standpoint, while also making it fast as hell.<p>After a few months of working on this as a side project, our benchmarking shows that we are on par with Pinecone and Qdrant for vectors, and our graph is up to three orders of magnitude faster than Neo4j.<p>Problems where a hybrid approach works particularly well include:<p>- Indexing codebases: you can vectorize code-snippets within a function (connected by edges) based on context and then create an AST (in a graph) from function calls, imports, dependencies, etc. Agents can look up code by similarity or keyword and then traverse the AST to get only the relevant code, which reduces hallucinations and prevents the LLM from guessing object shapes or variable/function names.<p>- Molecule discovery: Model biological interactions (e.g., proteins → genes → diseases) using graph types and then embed molecule structures to find similar compounds or case studies.<p>- Enterprise knowledge management: you can represent organisational structure, projects, and people (e.g., employee → team → project) in graph form, then index internal documents, emails, or notes as vectors for semantic search and link them directly employees/teams/projects in the graph.<p>I naively assumed when learning about databases for the first time that queries would be compiled and executed like functions in traditional programming. Turns out I was wrong, but this creates unnecessary latency by sending extra data (the whole written query), compiling it at run time, and then executing it. With Helix, you write the queries in our query language (HelixQL), which is then transpiled into Rust code and built directly into the database server, where you can call a generated API endpoint.<p>Many people have a thing against “yet another query language” (doubtless for good reason!) but we went ahead and did it anyway, because we think it makes working with our database so much easier that it’s worth a bit of a learning curve. HelixQL takes from other query languages such as Gremlin, Cypher and SQL with some extra ideas added in. It is declarative while the traversals themselves are functional. This allows complete control over the traversal flow while also having a cleaner syntax. HelixQL returns JSON to make things easy for clients. Also, it uses a schema, so the queries are type-checked.<p>We took a crude approach to building the original graph engine as a way to get an MVP out, so we are now working on improving the graph engine by making traversals massively parallel and pipelined. This means data is only ever decoded from disk when it is needed, and parts of reads are all processed in parallel.<p>If you’d like to try it out in a simple RAG demo, you can follow this guide and run our Jupyter notebook: <a href="https://github.com/HelixDB/helix-db/tree/main/examples/rag_demo">https://github.com/HelixDB/helix-db/tree/main/examples/rag_d...</a><p>Many thanks! Comments and feedback welcome!

Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

Hey HN, we want to share HelixDB (<a href="https://github.com/HelixDB/helix-db/">https://github.com/HelixDB/helix-db/</a>), a project a college friend and I are working on. It’s a new database that natively intertwines graph and vector types, without sacrificing performance. It’s written in Rust and our initial focus is on supporting RAG. Here’s a video runthrough: <a href="https://screen.studio/share/szgQu3yq" rel="nofollow">https://screen.studio/share/szgQu3yq</a>.<p>Why a hybrid? Vector databases are useful for similarity queries, while graph databases are useful for relationship queries. Each stores data in a way that’s best for its main type of query (e.g. key-value stores vs. node-and-edge tables). However, many AI-driven applications need <i>both</i> similarity and relationship queries. For example, you might use vector-based semantic search to retrieve relevant legal documents, and then use graph traversal to identify relationships between cases.<p>Developers of such apps have the quandary of needing to build on top of two different databases—a vector one and a graph one—plus you have to link them together and sync the data. Even then, your two databases aren't designed to work together—for example, there’s no native way to perform joins or queries that span both systems. You’ll need to handle that logic at the application level.<p>Helix started when we realized that there are ways to integrate vector and graph data that are both fast and suitable for AI applications, especially RAG-based ones. See this cool research paper: <a href="https://arxiv.org/html/2408.04948v1" rel="nofollow">https://arxiv.org/html/2408.04948v1</a>. After reading that and some other papers on graph and hybrid RAG, we decided to build a hybrid DB. Our aim was to make something better to use from a developer standpoint, while also making it fast as hell.<p>After a few months of working on this as a side project, our benchmarking shows that we are on par with Pinecone and Qdrant for vectors, and our graph is up to three orders of magnitude faster than Neo4j.<p>Problems where a hybrid approach works particularly well include:<p>- Indexing codebases: you can vectorize code-snippets within a function (connected by edges) based on context and then create an AST (in a graph) from function calls, imports, dependencies, etc. Agents can look up code by similarity or keyword and then traverse the AST to get only the relevant code, which reduces hallucinations and prevents the LLM from guessing object shapes or variable/function names.<p>- Molecule discovery: Model biological interactions (e.g., proteins → genes → diseases) using graph types and then embed molecule structures to find similar compounds or case studies.<p>- Enterprise knowledge management: you can represent organisational structure, projects, and people (e.g., employee → team → project) in graph form, then index internal documents, emails, or notes as vectors for semantic search and link them directly employees/teams/projects in the graph.<p>I naively assumed when learning about databases for the first time that queries would be compiled and executed like functions in traditional programming. Turns out I was wrong, but this creates unnecessary latency by sending extra data (the whole written query), compiling it at run time, and then executing it. With Helix, you write the queries in our query language (HelixQL), which is then transpiled into Rust code and built directly into the database server, where you can call a generated API endpoint.<p>Many people have a thing against “yet another query language” (doubtless for good reason!) but we went ahead and did it anyway, because we think it makes working with our database so much easier that it’s worth a bit of a learning curve. HelixQL takes from other query languages such as Gremlin, Cypher and SQL with some extra ideas added in. It is declarative while the traversals themselves are functional. This allows complete control over the traversal flow while also having a cleaner syntax. HelixQL returns JSON to make things easy for clients. Also, it uses a schema, so the queries are type-checked.<p>We took a crude approach to building the original graph engine as a way to get an MVP out, so we are now working on improving the graph engine by making traversals massively parallel and pipelined. This means data is only ever decoded from disk when it is needed, and parts of reads are all processed in parallel.<p>If you’d like to try it out in a simple RAG demo, you can follow this guide and run our Jupyter notebook: <a href="https://github.com/HelixDB/helix-db/tree/main/examples/rag_demo">https://github.com/HelixDB/helix-db/tree/main/examples/rag_d...</a><p>Many thanks! Comments and feedback welcome!

Show HN: HelixDB – Open-source vector-graph database for AI applications (Rust)

Hey HN, we want to share HelixDB (<a href="https://github.com/HelixDB/helix-db/">https://github.com/HelixDB/helix-db/</a>), a project a college friend and I are working on. It’s a new database that natively intertwines graph and vector types, without sacrificing performance. It’s written in Rust and our initial focus is on supporting RAG. Here’s a video runthrough: <a href="https://screen.studio/share/szgQu3yq" rel="nofollow">https://screen.studio/share/szgQu3yq</a>.<p>Why a hybrid? Vector databases are useful for similarity queries, while graph databases are useful for relationship queries. Each stores data in a way that’s best for its main type of query (e.g. key-value stores vs. node-and-edge tables). However, many AI-driven applications need <i>both</i> similarity and relationship queries. For example, you might use vector-based semantic search to retrieve relevant legal documents, and then use graph traversal to identify relationships between cases.<p>Developers of such apps have the quandary of needing to build on top of two different databases—a vector one and a graph one—plus you have to link them together and sync the data. Even then, your two databases aren't designed to work together—for example, there’s no native way to perform joins or queries that span both systems. You’ll need to handle that logic at the application level.<p>Helix started when we realized that there are ways to integrate vector and graph data that are both fast and suitable for AI applications, especially RAG-based ones. See this cool research paper: <a href="https://arxiv.org/html/2408.04948v1" rel="nofollow">https://arxiv.org/html/2408.04948v1</a>. After reading that and some other papers on graph and hybrid RAG, we decided to build a hybrid DB. Our aim was to make something better to use from a developer standpoint, while also making it fast as hell.<p>After a few months of working on this as a side project, our benchmarking shows that we are on par with Pinecone and Qdrant for vectors, and our graph is up to three orders of magnitude faster than Neo4j.<p>Problems where a hybrid approach works particularly well include:<p>- Indexing codebases: you can vectorize code-snippets within a function (connected by edges) based on context and then create an AST (in a graph) from function calls, imports, dependencies, etc. Agents can look up code by similarity or keyword and then traverse the AST to get only the relevant code, which reduces hallucinations and prevents the LLM from guessing object shapes or variable/function names.<p>- Molecule discovery: Model biological interactions (e.g., proteins → genes → diseases) using graph types and then embed molecule structures to find similar compounds or case studies.<p>- Enterprise knowledge management: you can represent organisational structure, projects, and people (e.g., employee → team → project) in graph form, then index internal documents, emails, or notes as vectors for semantic search and link them directly employees/teams/projects in the graph.<p>I naively assumed when learning about databases for the first time that queries would be compiled and executed like functions in traditional programming. Turns out I was wrong, but this creates unnecessary latency by sending extra data (the whole written query), compiling it at run time, and then executing it. With Helix, you write the queries in our query language (HelixQL), which is then transpiled into Rust code and built directly into the database server, where you can call a generated API endpoint.<p>Many people have a thing against “yet another query language” (doubtless for good reason!) but we went ahead and did it anyway, because we think it makes working with our database so much easier that it’s worth a bit of a learning curve. HelixQL takes from other query languages such as Gremlin, Cypher and SQL with some extra ideas added in. It is declarative while the traversals themselves are functional. This allows complete control over the traversal flow while also having a cleaner syntax. HelixQL returns JSON to make things easy for clients. Also, it uses a schema, so the queries are type-checked.<p>We took a crude approach to building the original graph engine as a way to get an MVP out, so we are now working on improving the graph engine by making traversals massively parallel and pipelined. This means data is only ever decoded from disk when it is needed, and parts of reads are all processed in parallel.<p>If you’d like to try it out in a simple RAG demo, you can follow this guide and run our Jupyter notebook: <a href="https://github.com/HelixDB/helix-db/tree/main/examples/rag_demo">https://github.com/HelixDB/helix-db/tree/main/examples/rag_d...</a><p>Many thanks! Comments and feedback welcome!