Launching today
Omnigraph
Open source graph database for your AI agents
188 followers
Open source graph database for your AI agents
188 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
AWS Startup AdvisorPersonalized AWS guidance that meets you where you’re already building
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 🚀🚀🚀
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?
@marina_dunaeva for sure! Omnigraph can accommodate pretty much any kind of data.
It's perfect for this type of OLAP workflow.
@marina_dunaeva Thank you, Marina!
Indeed, this is a very good use case for Omnigraph. Companies, people, suppliers, competitors and events are nodes, and "works at", "supplies", "competes with", "speaks at" are edges between them. You describe this in the schema once, and then agents load data from HubSpot and other sources into the same graph.
After that an agent can answer questions like "who decides at this company, where can I meet them in the next months, what can we talk about".
One caveat: Omnigraph stores and connects the data, it does not pipeline it. Scraping and CRM sync you need to solve separately.
We do smth very similar to that for our own GTM. Here is a sneak peek of our internal graph:
@pronskiy Oh, that’s really cool! Thanks for sharing a real life use case :) it looks so structured, like it.
Yeah, looks like the first big challenge we’d need to figure out the data collection part and then come back to Omnigraph.
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👀
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.
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.
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