Omnigraph: a lakehouse graph engine with branch and merge for agent fleets
Lakehouse native graph engine with git-style workflows
At a glance
- What is it?
- Omnigraph stores a property graph in Lance columnar files on object storage and manages it Terraform-style from a cluster directory, with Git-style branches so parallel agents can write without stepping on each other. The design is coherent and the operational story is unusually complete; the cost is a young project with a preview-grade Azure path and no published query benchmark.
- Who is it for?
- Adopt Omnigraph if you are building multi-agent memory or a context graph, you already run S3-compatible object storage, and you can accept a project whose newest release line is v0.10.0 with an edge channel alongside it.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Omnigraph is aimed at: many writers, one graph
Most graph databases assume a small number of writers and a single live state. Omnigraph assumes the opposite. Its README describes it as the operational state and coordination layer for fleets of agents, with hundreds of agents enriching the graph on parallel isolated branches that are reviewed and merged Git-style. That is a specific bet: that the hard part of agent memory is not traversal speed but concurrent mutation, review, and rollback. A branch-per-agent or branch-per-task model means a failed extraction run does not corrupt shared state, and a merge is an explicit review step rather than an implicit overwrite. The intended audience follows from that. The README lists company brain, agentic memory, context graph, dev graph, and R&D/ML data layer as target use cases, and every one of them involves either multiple automated writers or a need to version the graph over time. If you have a single application writing to a graph and reading it back, the branching machinery is overhead you will pay for and not use.
How a cluster directory becomes a running server
The unit of deployment is a cluster: a directory that declares graphs, schemas, stored queries, and policies as code. The README's example lays out company-brain/ with cluster.yaml, a people.pg schema file, a queries/ directory containing .gq files, and a base.policy.yaml Cedar bundle. The cluster.yaml carries a version field, metadata, a storage URI (s3://company/clusters/company-brain in the example), a graphs map binding a graph id to its schema and query directory, and a policies map with a file and an applies_to list. The comment in the README states that every query <name> in queries/*.gq registers, which means the query files are not just source, they are the declaration. That is a meaningful design choice: there is no separate registry step to drift out of sync with the files on disk. The lifecycle is Terraform-shaped. cluster validate parses and typechecks everything, cluster plan previews what apply would do, and cluster apply creates each graph, applies its schema, and publishes queries and policies into what the README calls a content-addressed catalog. The README says apply is idempotent and that re-running is always safe. omnigraph-server then boots from the cluster directory and brings every graph online at /graphs/{id}/..., each behind its own policy. Storage resolves through cluster.yaml rather than through a separate server config, so the cluster directory is the single source of truth for both the CLI and the server.
Lance on object storage, and what that buys and costs
The storage layer is Lance, a columnar format the README describes as branchable and time-travelable, with native blob-as-data for documents, images, and video. Omnigraph writes Lance over the standard S3 API, so the same code path serves RustFS or MinIO on-prem and AWS S3, R2, or GCS in the cloud via AWS_* environment variables. The README states that the ledger, catalog, and graph data all live under the storage URI. Two consequences follow. First, your data stays in a bucket you control, which matters for the VPC, on-prem, and hybrid deployments the README names. Second, the branch and time-travel semantics are inherited from the format rather than bolted on above it, which is why a branch can span the whole graph rather than a single table. The cost is that object storage is not a local disk. Every read and write is an object-store operation with the latency that implies, and the README offers no caching layer or local-disk mode. For a graph small enough to sit in memory, this architecture is strictly more machinery than you need. The README also notes that native az:// roots are a qualification preview: code, Azurite validation, and a live managed-identity smoke proof are described as complete, while adversarial qualification remains pending. Treat Azure as unproven.
Retrieval in one runtime, and the query surface
The README lists graph traversal, vector ANN, full-text search, and Reciprocal Rank Fusion as capabilities of one query runtime, and the repository topics name Apache Arrow and DataFusion. The practical reading is that the engine is built on DataFusion over Arrow, so a query can combine a traversal with a vector nearest-neighbour lookup and a text match, then fuse the rankings, without shipping intermediate results between systems. For context assembly that is the whole point: you want one call that returns a ranked set of nodes and their blobs, not three calls you merge in application code. The README does not document the query language beyond the .gq file extension and the query <name> declaration syntax, so the shape of a fused query is not something I can describe from the supplied material. If you are evaluating this, the CLI reference and the cookbooks are where that detail lives, and the presence of a query linting step in the shipped agent skill suggests the language has enough structure to be statically checked before it runs.
Getting it running: install, declare, converge
Installation is a shell script from the repository, which places omnigraph and omnigraph-server into ~/.local/bin from published release binaries, or a Homebrew tap at ModernRelay/tap/omnigraph. There is also an agent-facing path: npx skills add ModernRelay/omnigraph@omnigraph installs the shipped omnigraph agent skill, which the README describes as covering cluster mode, the two config surfaces, schema evolution, query linting, data writes, branches, Cedar policy, and common gotchas. The README also includes a paste-ready prompt for setting up a cluster from scratch with a coding agent, and points at ModernRelay/omnigraph-cookbooks for starter graphs with seed data. The operational sequence is three commands: omnigraph cluster validate, then omnigraph cluster plan, then omnigraph cluster apply, followed by omnigraph-server --cluster company-brain. Note the README's warning that Azure users must use the checked-in admission wrapper for every writer, including cluster apply and the server, rather than the bare commands. That is an unusual constraint and worth reading in docs/user/deployment.md before you plan an Azure deployment.
Where the design will bite you
Three limitations are visible in the material. The first is maturity. The release list shows v0.9.0 in August 2026, v0.10.0 later that same month, and a separate edge channel dated April 2026. An edge channel that predates the numbered releases is a signal that the project ships continuously and that version numbers do not describe a stable surface. The second is concurrency across regions. Branch and merge is a strong answer to conflicting writers, but it is a merge-based answer. If two agents modify the same node on different branches, someone resolves that conflict at merge time. The README does not describe an automatic conflict resolution strategy, so assume manual review is part of the workflow. The third is the storage dependency. If your organisation cannot run S3-compatible storage, or cannot run it near the compute, the object-store round trips will dominate. There is no documented embedded or single-file mode. A related gap: the README makes no performance claim and publishes no benchmark, so any throughput or latency expectation you bring is unverified by the project itself.
How it differs from a conventional graph database
A conventional graph database such as Neo4j keeps the graph in a purpose-built store with its own transaction log, and you get durability and isolation from that engine. Versioning, if you want it, is something you build on top with application-level snapshots or a temporal modelling pattern. Omnigraph inverts this. The durable substrate is a columnar file format on object storage, and versioning is a first-class operation at the storage layer, so a branch is cheap and a merge is an explicit reviewed action. The trade is that you inherit the file format's read patterns rather than a graph-native traversal engine, and you take on object-store latency per operation. The other comparison worth drawing is with the lakehouse table formats themselves. Iceberg and Delta give you snapshot isolation and time travel over tables, but they are table-oriented and do not model a property graph with schemas, stored queries, and per-graph Cedar policies. Omnigraph is closer to a control plane over Lance than to a database engine in the traditional sense, and the Terraform-style apply/plan vocabulary is the clearest evidence of that intent.
Maintenance, upgrades, and the licence
The MIT licence is permissive and imposes no copyleft obligation on your cluster definitions, schemas, or query files; as always, that is a description of the licence text and not legal advice about your situation. On maintenance, the material supports a few concrete observations. The project ships an edge channel alongside numbered releases, so you should decide deliberately whether you track edge or pin to v0.10.0. The cluster directory is the upgrade surface: because cluster.yaml, the .pg schemas, the .gq queries, and the policy bundles are all versioned files, an upgrade means re-running omnigraph cluster validate and omnigraph cluster plan to see the diff before apply touches the catalog. The README states that apply is idempotent, which makes re-running safe but does not make schema changes free. The shipped agent skill explicitly lists schema evolution as a covered topic, which suggests schema changes are common enough to warrant a documented playbook. Budget for reading that playbook before your first schema migration rather than after.
Editorial conclusion
Adopt Omnigraph if you are building multi-agent memory or a context graph, you already run S3-compatible object storage, and you can accept a project whose newest release line is v0.10.0 with an edge channel alongside it. Do not adopt it if you need multi-region writes against one graph, if you require a query planner that is not DataFusion, or if you need Azure Blob today, since the README labels native az:// roots a qualification preview and points Azure users at a checked-in admission wrapper instead of the bare CLI commands. Before committing, run omnigraph cluster validate and omnigraph cluster plan against your own cluster.yaml, and confirm that your storage backend is covered by the non-preview list (RustFS, MinIO, AWS S3, R2, GCS).
Community notes