ModernRelay/omnigraph

The problem

Once more than one agent or service works over the same knowledge, the hard part stops being retrieval and becomes coordination: who wrote what, which version is authoritative, and how do you review a change before it lands in production context. Most teams bolt this together from a vector store, a relational database and a pile of glue code, and inherit an unversioned, untyped mess. Omnigraph addresses that by making the graph itself the durable shared state, with branching, merge and a typed ontology as core primitives rather than afterthoughts.

What's different

Compared with mainstream property-graph databases such as Neo4j, the distinguishing move is not the graph model but the operations model: branching with three-way merge and time travel across the whole graph, Terraform-style cluster plan/cluster apply, and Cedar policy enforced server-side on every write path. It also puts graph traversal, vector ANN, full-text and rank fusion in one runtime, where the usual approach is a graph store plus a separate vector database stitched together in application code. Storage is deliberately boring: Lance files on S3-compatible object storage, so the data is open and not trapped in a proprietary on-disk format. The trade-off is that you inherit the constraints of object storage and the Lance format instead of tuning a dedicated graph engine.

Who it's for

Teams building agent memory, a company knowledge graph or a dev-issue dependency graph that several agents and humans write to concurrently will find the branch-and-merge model genuinely useful. Platform engineers who already run S3 and want versioned, auditable state fit well. Teams that only need fast traversal on a single node, or shops without object-storage infrastructure, should look at a conventional graph database; folks wanting a pure vector search library should stay with dedicated tools.

Cost of adoption

Rust is used throughout, with release binaries plus Homebrew and a curl install script. A cluster is a real deployment: config bundle, policy files, bootstrap, writer ownership transfer and authentication. Object-store variants are documented, with Azure needing an admission wrapper and Azure writer support marked preview. The API is at 0.14 and client contracts are pinned to the server version, so upgrades need attention. The project is MIT licensed and young, and the README is strong on operations but thin on benchmark or scale evidence.

Verdict

This is a brand-new project, not an established one: 197 days old, 1,730 stars, and a single weekly Rust board appearance at #12 with +397 stars. The Hacker News thread drew 3 points and no comments, so the spike looks driven by a trend listing rather than broad practitioner validation. The design ideas, branching plus typed schema plus open object storage, are coherent and address a real coordination gap, but at 0.14 with a pinned client contract you should treat it as early-adopter territory. Worth a prototype if the branching model matches your workflow; not yet a safe default for production context stores.