pgGraph
There are two major and very different bets on graph-in-Postgres: pgGraph vs. Apache AGE.
The “graph inside Postgres” space got more interesting with pgGraph, a brand-new Rust-based PostgreSQL extension that adds graph traversal, shortest-path, and relationship queries directly on top of your existing tables. Foreign keys become edges. Your tables stay the source of truth. No new query language required, everything surfaces through functions in a graph schema, callable from plain SQL. It’s early alpha, honest about it, and worth watching.
Apache AGE takes a fundamentally different architectural stance. It ships its own property graph model inside Postgres, with dedicated vertex/edge storage and openCypher as the query language. You’re essentially running a graph database that happens to live in the same process as your relational engine. The power is real Cypher, the property graph model is well-understood but you’re committing to a separate data model and a learning curve that not every team wants.
In essence, AGE adds a graph database to Postgres while pgGraph adds graph queries to your existing Postgres schema.
That’s not a minor implementation detail. It’s a different theory of where graph capability should sit in your stack. pgGraph’s approach means zero migration cost and zero dual-write overhead but you’re working with adjacency structures that emerge from relational design, which has real limits for deeply connected, heterogeneous graphs. AGE gives you a first-class property graph, but you’re managing two models.
For knowledge graph work (my cup of tea) the honest answer is that neither is a drop-in solution for production-grade entity graphs with rich ontological structure. But pgGraph’s philosophy (your schema is already a graph, let’s query it that way) is intellectually clean and worth taking seriously. The Rust implementation and pgrx foundation suggest the performance story will be good once it matures. Something to keep an eye on.