Omnigraph

Open source graph database for your AI agents

Open Source

Developer Tools

Database

Visit WebsiteSee on Product HuntTwitter ⧉Github ⧉

Having agents work on shared data without overwriting each other's changes is a big plus for teams

Congrats on the launch, @ragnor and team! We’ve rebuilt our entire internal operating system on Omnigraph as the retrieval substrate our agents run on. The improvement in retrieval quality and speed we've seen across many use cases is insane. We’re still in the very early stages of what’s possible to build on top of Omnigraph, so we’re really excited to keep working with it 🚀

Hey Product Hunt, Ragnor from Modern Relay here!

Before starting Omnigraph, I built infrastructure in biotech companies to automate the drug discovery process. The big learning was that every company runs on a "world model": what it believes about the world, the market and itself, the rules it works under, and how it turns all of that into actions. |

Today that model is implicit and lives in scattered tools and people's heads. And any company that seriously wants to automate work in the background and leverage AI beyond chat bots needs to make that world model explicit.

With Omnigraph, we built the infrastructure for companies to build and own their world model as a machine-readable interconnected graph of a company's knowledge - designed to be continuously maintained and improved by agents.

The Git-like branching for agent writes is the part that sold me — most agent memory tools let agents write freeform and just hope nothing conflicts, so having each run on its own branch with review and merge is a real answer to that mess. I'm curious about the typed ontology side though: when an agent runs into something that doesn't fit the schema, does it propose a schema change for review, or does it fail closed? That edge seems like where the design either stays clean or gets messy over time.

Whats the first use case where it feels clearly better than just keeping everything in a normal database?

I used Omnigraph to build a second brain and it works like magic. Really great product!

Congrats on the launch, @altshuler and team!

I’ve known Andrew for a long time. Many people are only now asking how graphs fit with agents. Andrew and his team have understood this for years, and it shows in every part of Omnigraph.

I’ve used it since nanograph, its predecessor, in two ways. First for product management. For years we broke complex products down into epics and features, using tools that only know hierarchies. But real products aren’t trees. A graph can hold that complexity, and agents can work with it.

Second, with that process we build software for the German construction industry, and it runs on Omnigraph too. Every industry dreams of a digital twin, whether for machines, patients or buildings. Agents finally make it possible. The open question is how to store knowledge about complex domains, and Omnigraph is the key to that.

Really interesting approach to the shared context problem for agent. What caught my attention was the branching + time travel piece. Congratulations!

Azim here, founding engineer at ModernRelay. Before this I worked on file formats and compression: FastLanes, which many databases borrowed from, and ALP, the float compression used in DuckDB, ClickHouse and Parquet.

Every new workload has produced its own class of database: transactional, analytical, graph, and lately vector. Agents are the next workload. Many agents write one store at once with no human in between, so a write needs a place to land before everyone else sees it. A read mixes structured lookup, text search and similarity search in one request.

None of the four fits. Transactional databases make every commit visible at once. Analytical databases want batch loads, not concurrent writers. Graph databases keep one history, no branches. Vector databases index similarity, not relationships. Run all four: four copies, no common snapshot.

Omnigraph is that one database, with one mechanism for each problem. Unchecked writes: typed schema enforced on write. A place to land: a branch per agent, merged into main when it's ready. Concurrent writers: optimistic concurrency. Mixed reads: one plan over traversal, full text and vector search, on one snapshot. One copy: Lance in your bucket.

Ask me anything.

Super excited to give this a try! As soon as I heard about it, I knew how useful it would be

I really like the design 😍 curious about a practical use case in B2B Sales. For example, connecting CRM HubSpot data with Linkedin Sales Navi insights, identify relevant decision-makers inside companies, then to map existing supplier and competitor relationships, and as to highlight potential places where I can meet these people in person(trade shows, conferences).

And as a final step, use profiles we've built to come up with relevant topics for the first touchpoint, conversation,presentation etc...

So, if we somehow figure out web scraping in our data protected world, Omnigraph could be pretty good place to store and connect all that data, right?

git style branching and merge for every agent write makes so much sense. congrats Andrew

Hey Product Hunt, I'm Andrew, co-founder and CTO of Modern Relay👋

I've worked with graphs for 18 years.
I saw the power of graphs and ontologies early on, and I've been betting on them ever since.

Once agents became the main operators of graphs, it was clear to me that graph databases had to be rebuilt from first principles. That's what we set out to do with Omnigraph.
We designed it as a database for agents first, and that choice shaped everything else.

Agents work at a very different pace from people. In one piece of work, an agent can create a branch, propose a schema change and bulk-load data. People don't work that way, and that's where conventional databases break.

Graphs are also getting much bigger, because agents process far more data than people do. Graph holds more than nodes and edges. It holds documents, video and other blobs that agents can embed and traverse from. Plus the full history of every change.

That's why Omnigraph runs on object storage.

The rest of the design follows from the same idea. A fully typed schema and declarative config make AI first-class operator of the database, and long-running agents can keep their state in it.

A graph used to be a small database on the side.
Now it's becoming the main database and the foundation of the context layer.
It holds the semantics agents need to reason over.

I'd love to hear about your experience. If you run agents on a graph today, where does it break first? And if you have questions about Omnigraph, ask them here. I'm around all day👀

branches make sense when multiple agents are proposing edits to the same shared graph

seeing which facts would be overwritten before merging would help catch conflicting updates

Congrats on the launch! How do agents usually write to the graph: do they get the schema up front, or does Omnigraph infer the entities and relationships from what they store? I'm also curious how it handles conflicting facts from different agent runs.

The visuals look super crisp, great job on that too! Also curious - how does it compare to the competitors?

Congrats on the launch, @pronskiy. I like that it’s basically Git for agents. Good luck today!