AgensGraph is an Apache-2.0, high-performance transactional graph database built as a fork of PostgreSQL, aimed at teams that want the property graph model and Cypher or ISO GQL queries while keeping graphs, relational tables and PostgreSQL transactions in one database.

What it is

AgensGraph is a graph database built inside PostgreSQL rather than beside it: it is a fork of PostgreSQL, not an extension, with the property graph model in the server itself. The model is deliberately thin — a graph is a schema, a label is a table, and a vertex or an edge is a row — which is why graph data and ordinary relational tables can live in one database and commit in one transaction. It belongs to the PostgreSQL ecosystem, and the repository's topics describe it as both a graphdb and a multi-model database.

The problem it solves is the split that normally appears when an application needs relational records and connected data at once: PostgreSQL holds the tables, a second system holds the graph, and the two are reconciled outside any shared transaction. AgensGraph replaces that second store. SQL, openCypher and ISO GQL (ISO/IEC 39075) can be mixed in a single statement, and the README notes that GQL and Cypher are one language with no mode switch, so a Cypher MATCH pattern can feed a relational join or be filtered by GQL clauses such as NEXT and FILTER.

Key capabilities

• Three query languages in one statement: SQL, openCypher and ISO GQL (ISO/IEC 39075), including GQL constructs such as LET, FILTER, FOR, NEXT, FINISH and CALL { }.
• A property graph model with vertex and edge labels, label inheritance, property indexes and constraints.
• Path queries through variable-length patterns and the shortestpath(), allshortestpaths() and dijkstra() functions, plus subqueries with CALL { }, OPTIONAL CALL, EXISTS { }, COUNT { }, COLLECT { } and VALUE { }.
• Typed columns that store chosen properties in typed, indexable columns rather than leaving them only in the property store.
• PostgreSQL behaviour carried over to graph data: transactions, roles, row-level security on labels enforced for Cypher reads and writes, streaming and logical replication, pg_dump and pg_restore, pg_upgrade and EXPLAIN.
• Vector and full-text search on properties through PostgreSQL extensions such as pgvector, supporting GraphRAG in one statement and MCP servers that give AI assistants and agents tool access.

Who uses it and how

• Enterprises already running PostgreSQL keep their operating model, since roles, row-level security, replication and pg_dump backups apply to graph data as well as to tables.
• Teams with mixed workloads join a Cypher MATCH result to a relational table in one query; the README's example joins matched movies against a my_ratings table and orders by star rating.
• AI and agent builders keep a knowledge graph, embeddings and agent memory in one database, exposing it to assistants through MCP servers.
• Security-sensitive deployments apply grants and row-level security to labels, with the same policies enforced for Cypher reads and writes.

Getting started

The quick start runs the published image skaiworldwide/agensgraph:v2.18.6.0-bookworm with docker run, then opens a session using agens -U agens -d postgres. A graph is created with CREATE GRAPH, selected with SET graph_path and populated with openCypher CREATE patterns.

How it compares

No competing graph database is named in the material for this entry, so AgensGraph stands alone in this registry and no product-by-product comparison is offered. Its distinguishing choice is structural: it is a fork of PostgreSQL rather than an extension loaded into an existing server, which is how the graph model, planner and query languages become part of the database itself rather than an add-on.

When to use it — and when not to

Self-hosting means operating a PostgreSQL-derived server, with the duties the README lists: roles and row-level security, replication, pg_dump and pg_restore backups, and pg_upgrade migrations between versions. No hosted service is described in the material here, where the documented path is a Docker container, and a project with purely relational needs gains nothing that upstream PostgreSQL does not already provide. The repository carries 141 open issues against roughly 1,500 stars and 160 forks, so a comparatively modest third-party ecosystem is a reasonable expectation.

docker run --name agensgraph -e POSTGRES_PASSWORD=agensgraph -d skaiworldwide/agensgraph:v2.18.6.0-bookworm
docker exec -it agensgraph agens -U agens -d postgres

CREATE GRAPH movies;
SET graph_path = movies;

CREATE (keanu:person {name: 'Keanu Reeves'}),
       (carrie:person {name: 'Carrie-Anne Moss'}),
       (matrix:movie {title: 'The Matrix', year: 1999}),
       (wick:movie {title: 'John Wick', year: 2014}),
       (keanu)-[:acted_in {role: 'Neo'}]->(matrix),
       (carrie)-[:acted_in {role: 'Trinity'}]->(matrix),
       (keanu)-[:acted_in {role: 'John Wick'}]->(wick);

MATCH (:person {name: 'Carrie-Anne Moss'})-[:acted_in]->(m:movie)<-[:acted_in]-(co:person)
RETURN co.name AS co_star, m.title AS movie;

    co_star     |    movie
----------------+--------------
 "Keanu Reeves" | "The Matrix"
(1 row)

MATCH (:person {name: 'Carrie-Anne Moss'})-[:acted_in*1..3]-(m:movie)
RETURN DISTINCT m.title AS reachable ORDER BY reachable;

  reachable
--------------
 "John Wick"
 "The Matrix"
(2 rows)

CREATE TABLE my_ratings (title text, stars int);
INSERT INTO my_ratings VALUES ('The Matrix', 5), ('John Wick', 4);

SELECT f.title, r.stars
FROM (MATCH (:person {name: 'Keanu Reeves'})-[:acted_in]->(m:movie)
      RETURN m.title AS title) AS f
JOIN my_ratings r ON r.title = f.title #>> '{}'
ORDER BY r.stars DESC;

    title     | stars
--------------+-------
 "The Matrix" |     5
 "John Wick"  |     4
(2 rows)

MATCH (p:person)-[:acted_in]->(m:movie)
RETURN p.name AS actor, count(m) AS movies
NEXT FILTER movies > 1
RETURN actor;

     actor
----------------
 "Keanu Reeves"
(1 row)

pip install "agensgraph-ai[all]"     # or one of: [mcp] [langchain] [llama-index] [lightrag] [cognee]