Postgres Property Graphs
Like MS SQL (in 2017!) and Oracle, that doesn’t make our beloved elephant a graph database.
PostgreSQL 19 ships SQL/PGQ, the ISO standard for property graph queries. You define a CREATE PROPERTY GRAPH over your existing tables and suddenly your relational schema is queryable with pattern-matching syntax (Cypher-ish) instead of chained JOINs. The graph is a read-only view over the same tables SQL has always queried. It’s a solution I suggested to various customers in the past (atop MSSQL) and it safes money and deployments.
But the architecture underneath hasn’t changed. A property graph in Postgres v19 is still a view over relational storage, executed by a planner built for joins and joins compose differently than traversal.
Memgraph benchmarked exactly this: exact N-hop reachability over the Pokec dataset (100K vertices, 1.77M edges), 1 to 5 hops, same data on both engines. Postgres moves from milliseconds into seconds while Memgraph stays under 100ms. At higher hops Postgres hits a 30-second timeout, Memgraph finishes in ~259ms. The gap isn’t a tuning problem, it’s what happens when you bolt a graph query surface onto a storage engine that was never designed to keep the graph as its primary structure. Each hop re-expands the search through join machinery.
SQL/PGQ is still a milestone worth taking seriously though, it legitimizes property graphs as a first-class relational concept and will pull a huge SQL-native audience toward graph thinking. Just don’t confuse “my database can express graphs” with “my database was built to traverse.”
❧ Postgres LPG: https://www.postgresql.org/docs/19/ddl-property-graphs.html ❧ Memgraph’s benchmark: https://memgraph.com/blog/postgresql-19-alternatives-memgraph