Launching today
Omnigraph
Open source graph database for your AI agents
118 followers
Open source graph database for your AI agents
118 followers
Omnigraph is an open-source object-storage native graph database with branching and typed ontology. It allows AI agents safely collaborate on shared knowledge. Give agents one typed graph with Git-like branching, review, and merge for every write, so changes can be validated before becoming shared context. Run it on your own S3-compatible storage, with semantic, keyword, and hybrid search plus graph traversal in one query. No hosted memory API or proprietary storage required.
Free
Launch Team / Built With
Framer AI AgentsDesign and publish professional sites with AI
Promoted
Hi Product Hunt 👋 Omnigraph is an open source graph database where agents can safely collaborate and write to the same graph.
It has a typed ontology, branches and time travel, and hybrid search with graph traversal in the same query. Your graph lives in your own object storage in an open format.
⭐ GitHub (MIT): github.com/ModernRelay/omnigraph
What can you use it for
More and more work inside a company is done by agents. They read the same data, write to it, make decisions on it, act on it. Without one shared world model they can trust, every agent ends up with its own version of the truth.
Omnigraph is a foundation for that shared world model. You can use it to build:
a company brain: people, projects, decisions, how they connect, all kept current by agents
context graphs for agents that work together on the same job
research graphs: papers, claims and the evidence behind them
You can check template ready-to-run graphs with real seed data (company brain, VC operating system, industry intel, beads): https://github.com/ModernRelay/omnigraph-cookbooks
What you get
Agents don't overwrite each other. Each one writes on its own branch, and you can review the changes before they reach main.
You always know who changed what and when, and you can see the graph as it was last week.
You define granular permissions to agents and humans in code.
Your schema says what can exist, and writes that don't fit are refused.
Agents find things by meaning or by keyword, then follow the connections over graph, in one query.
The graph lives in your own S3 bucket as open files you can take anywhere.
Every company needs a context layer, and we built Omnigraph to be the foundation for it.
Try it
The fastest way is to let your agent do it. Paste this into Claude Code, Codex or any coding agent:
Thanks @benln for hunting us! The whole team is here all day: @ragnor, @altshuler, @pronskiy, @azim_afroozeh. Ask us anything!
@benln @ragnor @pronskiy @azim_afroozeh 🚀🚀🚀
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👀
The visuals look super crisp, great job on that too! Also curious - how does it compare to the competitors?
@uddipta Thanks, Uddipta!
Short version: we built Omnigraph for multiple long-running agents writing to the same graph. Most graph databases assume a single application in control of the writes.
Typed schema: most graph databases are schema-optional, so agents drift. One writes Jack → spouse of → Jill, the next writes Jack → husband of → Jill. With Omnigraph you declare the schema up front and it's enforced on every write.
Branches: elsewhere agents write straight into live data. With us each agent can work on its own branch, then you or another agent review the diff and merge only what's good.
Open storage: data sits in an open format (Lance) on any S3-compatible storage, separate from compute. Most graph databases use a proprietary format and tie storage to compute.
It's also MIT licensed, and graph, vector and full-text search run in one engine.
What are you building? Happy to tell you honestly whether Omnigraph fits.
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, @pronskiy. I like that it’s basically Git for agents. Good luck today!
@pronskiy @codingwisely Thank you, Vladimir!
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.
@zain_sheikh Thanks, Zain!
Agents get the schema up front. It's a deliberate design choice and core part of Omnigraph. The schema is declarative, typed, and enforced on every write. You describe node and edge types once, and the agent reads the schema before it writes. This is how agents know the ontology. So they make fewer errors, and they also understand what the data means.
About conflicting facts. Each agent run can work on its own branch. If two runs changed the same node in different ways, the merge stops and nothing gets into main. You get a list of conflicts, and then you or another agent decide which version to keep.