HydraDB

Last week's Graph Club session on GNN-RAG sparked a good discussion on the tradeoffs of common graph-based retrieval frameworks. GraphRAG is expensive to build and query, and GNNs still struggle to hold accuracy on complex multi-hop questions and are difficult to interpret. The coming week, we will be discussing HippoRAG: Neurobiologically Inspired Long-Term Memory for Large Language Models. Even today, most RAG systems retrieve passages independently. This system works until an answer requires connecting information scattered across documents. The fundamental direction HippoRAG takes is towards attempting to make LLM memory work more like human memory. Inspired by how the hippocampus helps us recall related information, it combines LLMs, knowledge graphs, and Personalized PageRank to connect concepts and retrieve across multiple hops in a single step. We'll get into the weeds of how HippoRAG turns text into a retrievable graph of connected knowledge, its strengths and weaknesses, and what this could hold for the future of long-term memory in AI systems. If you work on RAG, agents, knowledge graphs, memory, or LLM infra, there's plenty to dig into here. Registration link in comments.

If you Google "best graph rag platform" right now, HydraDB shows up first in organic search results. That is not an accident Six months ago not many people were searching for this term. Once Microsoft's GraphRAG work went mainstream and teams started hitting the wall where flat retrieval stops working on connected data, "best graphrag platform" started showing up in our demo requests every week. The reason we are the first result is not a marketing budget. It is our team. The engineers who shipped benchmarks other companies would have quietly ignored. The DevRel and content people who spent late nights writing guides that actually explain how graph retrieval works instead of pitching a product. Everyone who answered questions on Reddit at 2am because someone was stuck. The founding customers who let us publish results and post their case studies. We are less than a year old and we already rank ahead of companies with a decade of head start on this. Ranking is a lagging indicator. What it actually measures is whether the work you have been doing quietly is showing up when someone with a real problem starts looking. This week it is. To everyone building on graphs right now: keep going. The market is finally catching up to where you have been for months

Every company has a wiki page that was completely accurate once. That was the last day anyone updated it. You know the one. The onboarding doc that references a tool you replaced eight months ago. The runbook that still says "ask Sarah" when Sarah left in March. Nobody let it go stale on purpose. It just stopped being anyone's job the moment the page was done. That is the problem with snapshots. They freeze a moment and call it truth. The company keeps moving. The doc stays behind. A graph works differently. New events attach to what already exists. A team change, a vendor swap, a process update. They connect to what they affect instead of sitting in a page nobody links to. So when an agent answers a question, it pulls from what is true now. Not what was true when someone last had time to write it down. Every team I talk to has documented things. That was never the problem. The problem is that none of it kept up.

Your agent books a dinner reservation in Brooklyn. The user moved to London last October. Everyone calls this a hallucination. It isn't one. The model reasoned perfectly. It read the memory layer, found a 2022 conversation about a favorite spot in Williamsburg, and planned a nice evening around it. Given that premise, the output was correct. The premise was wrong, because the memory layer had silently overwritten the correction and handed back the stale fact with total confidence. That's a database failure wearing a model failure's clothes. And it matters which one you think it is, because if you think it's the model, you go tune prompts and swap retrieval heuristics and adjust scoring functions, and none of that touches the actual bug. Most memory layers handle a state change by overwriting the old value. Reasonable default for most software. Destructive for agents, because the old value wasn't wrong. It was true then. You need both, and you need to know which one applies to the question being asked. Every long-running agent hits this within weeks of real traffic. We wrote up the architecture that fixes it. Link in comments.

Almost everyone building agents starts the same way. You already run Postgres, so you add pgvector and call it your memory layer. That holds up for a while. Then someone asks the agent a question like "which tool did the person who uploaded this doc use last week, and do they still have access?" That's a multi-hop question, and in Postgres you answer it with recursive CTEs. The planner can't push predicates down through the recursion, so every step gets materialized on its own. Latency climbs and your agent gets slow. Going the other direction doesn't fix it either. Flat vector stores are fast at semantic recall, but they have no idea what's related to what, or what's still true. Cosine similarity will happily hand back something relevant and completely out of date. Agent context is graph shaped. Flat storage drops the parts that connect it. We put together a breakdown of which architecture actually fits which workload (simple RAG, long-running stateful agents, multi-agent setups, regulated environments) plus the five things worth checking before you commit to any of them. Want to work out where your setup lands? Read more about this here: → https://lnkd.in/g4nWvS8F

One of the most valuable software companies in the world built a massive part of its business on a word most engineers skip past. Ontology. Palantir Technologies made it the core of their entire platform. Not a schema. Not a data catalog. An operational layer that maps every dataset to real-world entities, relationships, and actions. A shared dictionary that every system and every workflow reads from. Why does that matter for agents? Because the moment your agent pulls data from more than one source, those sources disagree. Your CRM calls it a "customer." Your support tool calls it an "account." Your billing system calls it a "subscriber." Same entity. Three definitions. No resolution. The agent doesn't know which one is right. So it picks whichever one it sees first and answers confidently. That's not a hallucination. That's a missing ontology. Any team running agents across more than one data source eventually hits a version of this. Most just haven't named it yet. Part 2 coming: what an ontology-first approach actually looks like in practice.

3 months ago we were 4 people. Today we're 20, across Engineering, GTM, and Applied AI. I am up until 3-4am most nights, and I feel like I still don't have enough hours in the day. That's a good problem to have, but it's a sign. We need more brilliant people in our SF office. We're hiring for: 1. Founding engineers - Experience building or scaling distributed systems, databases, or storage infrastructure 2. Founding GTM - Own revenue pipeline end to end 3. Community Lead - Runs killer events & attend conferences 4. DX engineer - Interface with our customers daily to understand how to improve our APIs, docs, and write great guides 5. Technical content creator - Own the content marketing pipeline We pay well with meaningful equity and are backed by some of the most amazing folks in the industry. --- update: a) there was an unbelievable amount of ai slot involved in 90% of the applications received b) we've started reaching out if we think we're a match