ModernRelay/omnigraph: a lakehouse graph engine with git-style branching

The problem Omnigraph targets: agent state that outlives a session

Most agent memory today is a vector index plus a hope. Omnigraph's README frames the project differently: it calls itself "the operational state and coordination layer for fleets of agents", where hundreds of agents write to the same graph on parallel isolated branches and every change is reviewed before it merges. That is a specific claim about concurrency and review, not about retrieval quality.

The intended users are teams building a company brain, durable agentic memory, a context graph of decision traces, a dev graph of issues and dependencies, or an R&D data layer where experiments are versioned for training and evaluation. All five share a shape: many writers, a schema that evolves, and a need to reconstruct what the graph looked like at an earlier point. If your graph has one writer and one reader, this is more machinery than the problem needs.

How Omnigraph works: a declared cluster over Lance files on object storage

A deployment is a cluster, which the README describes as a multigraph config directory that declares its graphs, schemas, stored queries and policies as code. 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 object store can be RustFS or MinIO on-prem, or AWS S3, R2 or GCS in the cloud through the AWS_* environment variables. Native az:// roots exist as a qualification preview, and the README is explicit that adversarial qualification is still pending.

Query is one runtime rather than a federation of three: graph traversal, vector ANN, full-text search and Reciprocal Rank Fusion are executed together for context assembly. The workspace Cargo.toml shows the dependency spine: arrow 58, datafusion 54, and lance pinned to exactly 11.0.0 across lance-core, lance-io, lance-select, lance-datafusion, lance-file, lance-index and lance-linalg. Pinning Lance to an exact version is a deliberate constraint; the comment in Cargo.toml notes that explicit V2_2 writes and a late-payload KNN ordering fence remain required, with details in docs/dev/lance.md. Upgrading Lance is therefore a coordinated change across the workspace, not a patch bump.

Security sits in the server process. Cedar policy is enforced server-side on every mutation, per-graph and server-wide, with bearer auth and actor/audit tracking. Policies are declared in the cluster directory and bound to graphs or to the whole cluster. The practical consequence is that a client cannot bypass policy by writing directly to the object store path, because the server is the only component that applies it.

Installing Omnigraph and converging a first cluster

The README gives two install paths. The script installs the omnigraph CLI and omnigraph-server into ~/.local/bin from published release binaries:

curl -fsSL https://raw.githubusercontent.com/ModernRelay/omnigraph/main/scripts/install.sh | bash

Homebrew users get the same pair from the project tap:

brew tap ModernRelay/tap
brew install ModernRelay/tap/omnigraph

After that, a cluster is a directory. The README's example declares storage, one graph, its schema file, a queries directory and a policy bundle:

version: 1
metadata:
  name: company-brain
storage: s3://company/clusters/company-brain
graphs:
  knowledge:
    schema: people.pg
    queries: queries/
policies:
  base:
    file: base.policy.yaml
    applies_to: [knowledge]

The README states that every query <name> in queries/*.gq registers, so the .gq files are the declaration rather than a build artifact. Convergence is three commands, and the README says apply is idempotent, so re-running is safe:

omnigraph cluster validate
omnigraph cluster plan
omnigraph cluster apply

validate parses and typechecks everything, plan previews the diff, and apply creates each graph, applies its schema, and publishes queries and policies into a content-addressed catalog. Then the server boots from the cluster directory and exposes each graph under /graphs/{id}/, with storage resolved through cluster.yaml:

omnigraph-server --cluster company-brain

For a container deployment, the Dockerfile builds from public.ecr.aws/debian/debian:bookworm-slim, copies omnigraph-server, omnigraph and omnigraph-azure-admission into /usr/local/bin, sets OMNIGRAPH_BIND to 0.0.0.0:8080, runs as the omnigraph user, and healthchecks http://127.0.0.1:8080/healthz every 30 seconds. If you have an agent that can read a URL and run a shell command, the README also ships an agent skill installable with npx skills add ModernRelay/omnigraph@omnigraph, and the cookbooks repository carries seed data for ready-to-run domains.

Where Omnigraph is the wrong tool

The most concrete limitation is stated by the project itself: native Azure Blob support is a qualification preview. The README says the code, Azurite validation and a live managed-identity smoke proof are complete, while adversarial qualification remains pending. The Dockerfile goes further and warns that an Azure writer must never be started through docker exec, ECS exec or railway shell; the server has to be quiesced and the writer run as a job through omnigraph-azure-admission. If your storage is Azure and your team does not want to adopt a special admission wrapper for every write path, this is not the version to build on.

The second constraint is operational weight. A cluster needs an object store, a server process and a policy bundle before the first query returns anything. Teams that want to open a file and run a query in the same minute will find that overhead disproportionate.

The third is the query surface. The README describes traversal, vector search, full-text and RRF in one runtime, and stored queries in .gq files, but it does not present a Cypher compatibility layer. Anyone arriving with a decade of Cypher or Gremlin and expecting it to port unchanged should check the query documentation before assuming parity. The README does not document rollback of an applied cluster change either; plan and apply are described, a revert is not.

How Omnigraph differs from Neptune, Neo4j and Kuzu

The nearest managed comparison is Amazon Neptune. Neptune is a service you point at; Omnigraph is a binary you run against a bucket you own. The README's framing, that your data never leaves your store, is the whole difference: there is no hosted control plane in the README, so backup, upgrade and uptime are yours.

Against Neo4j the split is storage format and versioning model. Neo4j keeps its own store and its own transaction log; Omnigraph writes Lance columnar files and treats branches as first-class, so an agent's work is an isolated branch merged on review rather than a transaction series on a shared graph. That is a real architectural divergence, and it is why the concurrency story reads more like git than like a database.

Kuzu is the closer contrast on deployment shape: an embedded analytical graph engine you link into a process. Omnigraph is the opposite end of that axis, a server with policy enforcement, bearer auth, audit tracking and object-storage roots. If your graph fits in one process, Kuzu is the smaller answer; if hundreds of agents write concurrently and you need review and audit, the embedded model stops fitting.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-09-10. Releases are frequent: v0.9.0 on 2026-08-07, v0.10.0 on 2026-08-31, and an edge channel dated 2026-04-10. The version numbering, still below 1.0, is the honest signal here: expect the cluster config surface to move.

Upgrade cost concentrates in two places. The workspace pins lance to =11.0.0 and keeps lance-core, lance-io, lance-select, lance-datafusion, lance-file, lance-index and lance-linalg in lockstep, so a Lance upgrade touches the whole workspace at once. The README also names two config surfaces, and the shipped agent skill covers schema evolution and query linting, which suggests schema changes are a routine operation rather than a rare migration. Run omnigraph cluster plan against a copy of production storage before any upgrade; the README describes plan as the preview of what apply would do, which is exactly the tool for that check.

The licence is MIT, which permits commercial use and modification. Note that the licence covers this repository; the Lance format, DataFusion and Arrow carry their own terms, and the README does not spell out those obligations. That is a question for your legal team, not something to infer from the MIT badge.

Editorial conclusion

Adopt Omnigraph if you already run an S3-compatible object store and want agent-written graph state that is versioned, branchable and policy-checked server-side; the install script and the cookbooks are the fastest way to find out. Do not adopt it if you want a single-node embedded graph, a Cypher-first query experience, or a managed service: there is no hosted offering described in the README, and the server is something you boot yourself with omnigraph-server --cluster. Before committing, verify three things: that your object store is reachable through the AWS_* environment variables, that a cluster plan against a throwaway storage prefix produces the diff you expect, and what your team's own review rule is for merging agent branches, because the tooling gives you the merge and not the policy.

Frequently asked questions

Official sources

1. License: MIT
2. ModernRelay/omnigraph on GitHub
3. Project website
4. README
5. Releases