Postgres Just Became a Graph Database. Nobody Needs a Fourth One.

pgGraph shipped as an alpha extension in August 2026. It adds bounded graph traversal, shortest-path queries, and connected-components analysis directly onto plain PostgreSQL tables. No migration. No second database. No new query language to learn.

That is not a small feature release. That is Postgres closing the last capability gap that used to justify standing up a specialized system next to it. Vector search, closed by pgvector in 2021. Full-text search, built in. Geospatial, PostGIS. Time-series, TimescaleDB. Graph traversal was the one workload Postgres genuinely could not do well, the one where "just write a recursive CTE" fell apart the moment a query went more than three or four hops deep. pgGraph is the extension that closes that gap, and it makes a specific, testable claim worth examining before anyone treats it as a reason to rip out a graph database, or a reason to never buy one.

The gap that just closed

Evokoa built pgGraph to answer a problem they describe plainly in the extension's launch post: existing options for multi-hop relationship queries were "either too slow for our agent workloads or required moving our entire system of record into a separate, heavy graph database." Recursive SQL handles two or three hops. Past that, Postgres's query planner starts re-deriving the same paths over and over, and latency falls off a cliff exactly when the query gets interesting.

The shape of the query barely changes. What changes is who does the work, and where the depth guard lives.

-- Before pgGraph: a bounded shortest-path query as a recursive CTE
WITH RECURSIVE paths AS (
  SELECT source_id, target_id, ARRAY[source_id] AS visited, 1 AS depth
  FROM edges
  WHERE source_id = $1

  UNION ALL

  SELECT e.source_id, e.target_id, p.visited || e.target_id, p.depth + 1
  FROM edges e
  JOIN paths p ON e.source_id = p.target_id
  WHERE e.target_id != ALL(p.visited)
    AND p.depth < 4  -- hand-rolled depth guard, easy to forget or get wrong
)
SELECT * FROM paths WHERE target_id = $2 ORDER BY depth LIMIT 1;
-- Cost grows with graph density; nothing stops a missing guard from taking the box down

-- After pgGraph: same tables, same source of truth, no ETL, no new database
SELECT * FROM graph.shortest_path(
  source => $1,
  target => $2,
  max_depth => 4
);
-- Walks a precomputed CSR adjacency array, O(1) per hop, bounded by a real circuit breaker

The mechanism pgGraph uses to avoid that is a derived index, not a rewrite of Postgres's storage engine. It builds a compressed sparse row (CSR) array over the tables an application selects, the same data structure graph engines have used internally for decades, and it keeps that array as a read-only artifact that never touches the source tables. When a query calls graph.search() or graph.shortest_path(), pgGraph walks the CSR array directly instead of asking Postgres's planner to re-derive adjacency through joins. Adjacency lookups become O(1), and bounded traversals ship with explicit circuit breakers so a runaway multi-hop query cannot take the database down, a real failure mode with naive recursive CTEs on dense graphs.

It supports PostgreSQL 14 through 18, ships under Apache-2.0, and installs the same way any other extension does: CREATE EXTENSION graph; after a Docker quickstart, a Homebrew tap, or a source build. No new server process. No sidecar to keep in sync. The source of truth stays exactly where it already is.

The extensions that stuck, pgvector, PostGIS, TimescaleDB, all share one trait: they added a capability without asking anyone to change where their data lives. pgGraph is the first one to try that for graph traversal specifically, and the CSR mechanism is a genuinely different approach from "add more indexes and hope."

What "multi-model" actually means, and where Postgres still isn't one

Google's own language for Spanner is direct: "Spanner Graph is a multi-model database that integrates graph, relational, search, and AI capabilities," with "full interoperability between GQL and SQL" so a team can pick the right query language per query instead of migrating data between systems. ArangoDB makes the same pitch from the open-source side: document, graph, and key-value models inside one engine, queried through a single language, AQL, built to combine graph traversals and document lookups in the same statement.

Both of those systems earned the "multi-model" label by being designed that way from the first commit. Postgres earned a version of the same label by accretion, fifteen years of extensions bolted onto a relational core that was never rearchitected to expect them. That difference in origin still shows up in real tradeoffs a CTO needs on the table before treating pgGraph as a drop-in Neo4j replacement.

Postgres multi-model means five extensions with five different interfaces: pgvector's operators, PostGIS's spatial functions, TimescaleDB's hypertables, full-text search's tsvector, and now pgGraph's graph.* function namespace. There is no unified query language across them the way AQL or GQL-plus-SQL unifies ArangoDB and Spanner. What Postgres offers instead is a unified storage and operational model: one WAL, one backup strategy, one connection pool, one set of access controls, regardless of how many extensions are loaded.

That is the honest distinction: Postgres is assembled multi-model, not native multi-model. It is a real difference, and it matters less than the origin story suggests, because the thing most teams are actually optimizing for is not query-language elegance. It is not having to run, patch, and staff a fourth database.

The case against reaching for a fifth database

Eight weeks into a fraud-detection feature at a previous company, I stood up a Neo4j cluster to trace transaction rings, three hops deep, across a few million accounts. Two engineers spent a sprint learning Cypher and building an ETL job to keep the graph in sync with the ledger sitting in Postgres. Six weeks later, a recursive CTE with a depth cap did the identical job on the same Postgres instance already holding the transactions. The Neo4j cluster got decommissioned before it ever saw production traffic. That was before pgGraph existed; a bounded CSR traversal would have made the decision to build it in the first place look even worse in hindsight.

That is not an argument that dedicated systems are never right. It is an argument that the decision to add one gets made too early, before anyone has measured whether the relational engine actually falls over. A 2025 academic study of polyglot persistence in microservices found what most engineering orgs learn the expensive way: adding database technologies increases total cost of ownership, because teams now carry backup, scaling, fault-tolerance, and security expertise across every stack they run, not just the one doing the most work.

That growth is not happening because Postgres is the newest or the flashiest option. It is happening because every extension that ships, pgvector, PostGIS, pgGraph, removes one more reason to reach for a fifth database before the workload has actually earned it.

Why the extension model keeps working

pgvector is the proof case, not a hypothetical. It launched in 2021 as a niche extension for storing embeddings next to relational data. It now sits at 22.7k GitHub stars and 1.3k forks, and managed Postgres providers, Supabase, Neon, AWS RDS among them, treat vector search as a headline feature rather than an afterthought. It went from "interesting side project" to "default vector store for most teams" in under three years, without a single team having to migrate off Postgres to get there.

That track record is also why the extension model earns trust that a brand-new standalone database has to build from zero. According to the 2025 Stack Overflow Developer Survey, 58.2% of professional developers already use PostgreSQL, more than the next four databases combined use of any single alternative. Every capability Postgres adds through an extension reaches that installed base immediately. A graph-native startup has to win adoption from scratch; pgGraph inherits it.

The installed base changes the math on every new extension

A dedicated graph database competing for adoption has to convince a team to learn a new operational model before it delivers a single query result. pgGraph's competition is a CREATE EXTENSION statement on infrastructure the team is already running, monitoring, and backing up. The switching cost is not zero, but it is an order of magnitude lower, and that gap is exactly what determined pgvector's adoption curve and is now set up to determine pgGraph's.

Where pgGraph is not ready yet

None of this makes pgGraph a finished product, and treating it like one before it earns that would repeat the mistake the Neo4j cluster made in reverse. It shipped as an alpha release. There is no published benchmark comparing its traversal latency against Neo4j or ArangoDB at scale, only the claim of microsecond-level lookups on the CSR array, unverified by anyone outside Evokoa yet. There is no Cypher-equivalent query language, no visual graph explorer, no query optimizer tuned specifically for graph pattern matching the way Neo4j's Cypher planner is.

The CSR index itself is a derived, read-only artifact, which is the right design for traversal speed and the wrong design for a graph that changes constantly. Every write to the source tables means the index eventually needs rebuilding, and Evokoa's documentation does not yet specify rebuild cadence, staleness tolerance, or what a query returns against a partially stale index under heavy write load. For a slowly-changing social graph or an organizational hierarchy, that is a non-issue. For a graph that mutates every second, a CTO needs that answer in writing before pgGraph touches anything that matters.

That is not a reason to wait a year before evaluating it. It is a reason to run it against a real workload with real write patterns before betting a roadmap on it, the same diligence any alpha-stage dependency earns regardless of who built it.

The real decision CTOs are making

The market for graph databases is real but still small next to Postgres's installed base: MarketsandMarkets sizes it at $0.65 billion in 2025, growing to a projected $2.14 billion by 2030. Neo4j alone passed $200 million in annual revenue in late 2024, and GraphRAG, using a knowledge graph to ground LLM retrieval, has become the first mainstream graph use case outside fraud detection and recommendation engines. That is a genuine, growing category. It is also a category most teams evaluating pgGraph are not actually in yet.

If graph traversal is one feature among many in a system Postgres already runs, the second question in that tree almost always resolves to "no", and pgGraph is the correct default. If the product is the graph, a social network's entire feed algorithm, a fraud engine processing billions of edges, a recommendation system where traversal latency is the core metric, a graph-native database earns its operational cost. Most teams evaluating pgGraph right now are the first case, not the second, and the honest read of the evidence says so.

Postgres did not become a graph database because graph databases stopped mattering. It became one because the extension model has now proven, five separate times, that it can absorb a capability that used to require a second system without asking anyone to leave the database they already trust with their system of record. The database already running in production just got another reason to stay the one running in production.

The question worth asking before the next vendor call is not whether Postgres can do this. It is whether the workload genuinely needs a fourth database, or whether it needs an engineer who spent an afternoon reading the pgGraph docs.

Sources

1. Evokoa - Introducing pgGraph (2026) - launch post explaining the problem pgGraph solves and its CSR-based traversal mechanism
2. Evokoa - pgGraph GitHub Repository (2026) - README covering installation, supported PostgreSQL versions (14-18), API functions, and Apache-2.0 license
3. Google Cloud - Spanner Graph Overview - official documentation describing Spanner Graph's multi-model architecture and GQL/SQL interoperability
4. ArangoDB - GitHub Repository - native multi-model database combining document, graph, and key-value models under AQL
5. Redgate / DB-Engines - PostgreSQL Leads H1 2026 Database Growth (2026) - press release with exact DB-Engines score changes for PostgreSQL, Databricks, MongoDB, Microsoft Fabric, and Snowflake
6. Stack Overflow - 2025 Developer Survey, Technology - professional developer database usage figures, PostgreSQL at 58.2%
7. pgvector - GitHub Repository - star and fork counts, feature set, and hosted-provider support for Postgres's vector extension
8. arXiv - Polyglot Persistence in Microservices: Managing Data Diversity in Distributed Systems (2025) - academic study on the total-cost-of-ownership and operational-complexity impact of running multiple database technologies
9. MarketsandMarkets - Graph Database Market Report - market sizing at $0.65 billion in 2025, projected $2.14 billion by 2030
10. Neo4j - The Graph Database Market Share Leader - Neo4j revenue figures and GraphRAG adoption context for dedicated graph databases

Working through the challenges in this post? I help engineering leaders and CTOs navigate complex technical decisions and scale high-performing teams. Schedule a consultation →