ArcadeDB vs PostgreSQL for Graph Queries: Why SQL/PGQ Doesn't Replace a Graph Database

Let’s start with the credit PostgreSQL deserves. It is one of the best relational databases ever built, and arguably the most important open-source DBMS of the last thirty years: community-governed, permissively licensed, famously careful about correctness, and extensible enough to carry PostGIS, pgvector, and a whole ecosystem on top. Its wire protocol has become a lingua franca that many other databases, ArcadeDB included, speak so they can reuse its drivers and tools. If you need a relational database, PostgreSQL is very hard to beat.

But when the use case is a real graph, it is not the best choice. Not even close.

That needs saying now, because when the PostgreSQL 19 betas shipped SQL/PGQ, the ISO SQL:2023 standard for property graph queries, one conclusion spread fast: PostgreSQL is a graph database now. “You don’t need Neo4j.” “I ran our Neo4j workload against it.”

Then, on September 7, 2026, the feature was reverted from PostgreSQL 19 over stability concerns. The earliest it can return is PostgreSQL 20, in September 2027.

The delay is not the interesting part. SQL/PGQ will land eventually, and the real question is: once it does, can PostgreSQL replace a graph database for a real graph workload? We ran the LDBC LSQB benchmark to find out. ArcadeDB finished all nine queries in 2.2 seconds. PostgreSQL needed 69.

What SQL/PGQ in PostgreSQL Actually Is

SQL/PGQ lets you declare a property graph over tables you already have, and query it with a pattern instead of a stack of joins. That is a genuine readability win. But the exobench analysis of the beta is clear about what it is: “deliberately not a graph storage engine. It is a rewriter.” Every MATCH compiles into the joins you would have written by hand, with identical execution plans.

The beta also left out most of what graph work needs:

• No variable-length paths: quantifiers like {1,5} were rejected.
• Read-only: writes go to the underlying tables, in plain SQL.
• No graph algorithms: no PageRank, no community detection.
• Schema-bound: every edge type is a table, declared up front.

Syntax Is Not Storage: Joins vs Index-Free Adjacency

In PostgreSQL, an edge is a row, so every hop is a B-tree search that gets slower as the table grows. In ArcadeDB, each vertex holds direct links (Record IDs) to its edges, so a hop is a pointer jump whose cost does not depend on the size of the database. That is index-free adjacency. The difference is invisible at one hop and dominant at three.

The Benchmark: LDBC LSQB, ArcadeDB vs PostgreSQL

LSQB is maintained by the Linked Data Benchmark Council, not by us: nine pattern-matching queries, with an official SQL version for relational systems and an official Cypher version for graph systems. We ran it at scale factor 1 (3.9 million vertices, 17.9 million edges). Since GRAPH_TABLE compiles to the same plan as those SQL joins, PostgreSQL’s numbers are exactly what SQL/PGQ would get.

ArcadeDB wins all nine, and the gap follows the shape of the query:

• Short patterns (Q2, Q5): 1.8x to 3x. Hash joins work here, and PostgreSQL does fine.
• Friends of friends (Q6): 161x. Only two hops, but 1.67 billion matches: 17.7 seconds of self-joins against 110 milliseconds of walking adjacency lists.
• Stars (Q4, Q7): hundreds of times. Every arm of the star is another join in PostgreSQL, and just another neighbor list of the same vertex in ArcadeDB.

The Memgraph team found the same curve on a different dataset: comparable up to three hops, a PostgreSQL timeout at five.

Beyond Fixed Patterns: What PostgreSQL Can’t Express Yet

LSQB uses fixed-length patterns only, the best case for SQL/PGQ. Real graph applications go further:

• Variable-length paths. “Within five hops of a known fraudster” needs a recursive CTE in PostgreSQL: 2.2 seconds on a 1 million node graph, and 6 seconds with emulated SQL/PGQ recursion, per exobench. In ArcadeDB it is one line: MATCH (a)-[:TRANSFER*1..5]->(b).
• Graph algorithms. None in PostgreSQL. ArcadeDB is fastest on 5 of the 6 LDBC Graphalytics algorithms, with PageRank in 0.10 seconds.
• Writes through the graph. CREATE and MERGE are ordinary transactional writes in ArcadeDB; in PostgreSQL the graph is a read-only view.
• New relationship types. A new edge type in ArcadeDB; a new table, a migration, and an ALTER PROPERTY GRAPH in PostgreSQL.

“But I Don’t Want Another Database”

That is the real appeal of SQL/PGQ, and it is fair. But if the goal is one database, it doesn’t have to be PostgreSQL. ArcadeDB is a complete ACID DBMS, not a graph add-on: relational records with schemas and constraints, plus graph, documents, vectors, full-text, time series, and geospatial data in the same transaction. That is also what makes it a natural fit for GraphRAG.

Your team keeps its tools: psql and PostgreSQL drivers connect over the wire protocol. One honest caveat: queries are ArcadeDB SQL or Cypher, not PostgreSQL’s SQL dialect. So:

1. PostgreSQL alone when relationships are a minor feature.
2. ArcadeDB alone for new applications or modest schemas: one engine, nothing to sync.
3. PostgreSQL plus ArcadeDB when an app is deeply tied to PostgreSQL SQL, PL/pgSQL, or extensions: keep it, and move the graph part, such as fraud rings, knowledge graphs, recommendations, access paths, or supply chains, into ArcadeDB.

PostgreSQL vs ArcadeDB: An Honest Guide

If relationships are a feature of your application, SQL/PGQ will be a welcome upgrade whenever it ships. If relationships are your application, a relational engine with graph syntax is still a relational engine.

Try It Yourself

The queries, datasets, and harness are public: see the benchmarks page and the runner on GitHub. If your numbers differ, send them to us. To try your own workload:

docker run --rm -p 2480:2480 -p 5432:5432 \
  -e JAVA_OPTS="-Darcadedb.server.rootPassword=playwithdata -Darcadedb.server.plugins=Postgres:com.arcadedb.postgres.PostgresProtocolPlugin" \
  arcadedata/arcadedb:latest

Then connect with psql, or open the Studio at http://localhost:2480 and write your first MATCH.