pgGraph Brings Graph Database Powers to Existing Postgres

pgGraph Overview

Evokoa released

as an open-source PostgreSQL extension. It runs graph search, traversal, shortest path, and relationship queries against ordinary Postgres tables. The project surfaced in GitHub Trending lists in recent weeks. Tables remain the source of truth while pgGraph maintains a derived graph index. Queries execute through SQL functions in the graph schema. The extension targets developers who already store data in Postgres and want to avoid a second database for graph workloads.

Core Features and Architecture

pgGraph discovers foreign key relationships between registered tables and builds an in-memory graph representation. You register tables once, then call functions such as graph.shortest_path or graph.traverse. The extension supports hop-limited searches and cross-table node lookups without writing recursive CTEs for every new schema.

The architecture keeps storage inside Postgres. No separate graph-specific files or daemons appear. Index updates occur when the quickstart scripts or manual refresh functions run. This design removes the need to duplicate data into systems like Neo4j or AgensGraph. Trade-offs include the cost of maintaining the derived index and the requirement to re-register tables after schema changes.

Installation and Quickstart

The repository supplies a single script for evaluation. Clone the repo and run scripts/quickstart.sh to launch a disposable Docker Postgres instance, install the extension, create sample tables, and execute demo queries. The same script accepts flags for an existing container or a pgrx source build.

For production testing, the Docker option isolates the instance cleanly. The pgrx path compiles the Rust-based extension against a local Postgres installation. Both routes expose the graph schema functions immediately after setup. Documentation lists the exact SQL calls needed to register tables and trigger index construction.

Trade-offs and Current Status

pgGraph remains in early alpha. The authors advise against production use until more stability data accumulates. Index rebuilds can become expensive on large tables, and query planning does not yet integrate with the Postgres optimizer. Users must handle concurrency and refresh timing themselves.

On the positive side, the extension works with existing foreign keys and standard SQL clients. No new query language or driver changes are required. Developers already comfortable with Postgres functions can adopt the graph calls incrementally. Feedback through the repository issues will shape future releases.

pgGraph in Practice

Teams that already run complex recursive queries on Postgres tables can replace them with the provided graph functions. Shortest-path lookups between entities become single function calls rather than multi-step CTEs. Search across registered nodes uses the same connection and transaction context.

The sandbox directory contains example datasets for experimentation. Streamlit integration in the quickstart lets you visualize paths without additional tooling. These pieces lower the barrier for testing whether the extension fits a given schema.

FAQs

Does pgGraph require data migration? No. Tables stay in place and continue to serve normal SQL workloads. pgGraph only adds an index layer on top.

Can I use pgGraph with my current ORM? Yes. The extension exposes ordinary SQL functions, so any ORM that can call raw SQL will work without modification.

How often should the graph index refresh? Refresh frequency depends on write patterns. The documentation suggests running the refresh function after bulk loads or on a schedule that matches acceptable staleness for your queries.

---

📖 Related articles

• Agentic Coding: Una Trappola per lo Sviluppo Software?
• Lean-ctx: Ottimizzatore Ibrido Riduce Consumo Token LLM del 89-99%
• Rust rivoluziona Claude Code: Avvio 2.5x più rapido e volume ridotto del 97%