Video summary

Postgres is dropping a crazy new feature

Main summary

Key takeaways

Technology

Postgres 19 (beta) Graph Property Queries

Postgres 19 (beta) introduces property graph queries, providing a standardized way to query graph-shaped data inside Postgres. It uses graph pattern matching syntax similar to Neo4j’s Cypher, while still keeping relational tables as the source of truth.

What problem it addresses

  • Relational databases store data in tables, represent relationships via foreign keys, and retrieve related information using joins.
  • Some domains are naturally expressed as graph data:
    • Nodes = entities (e.g., users, products)
    • Edges = relationships/actions between entities (e.g., user follows user, customer buys product)
  • Native graph databases (e.g., Neo4j) tend to excel when the relationships themselves are the query, especially for deep, multi-hop traversals.

How Postgres 19’s graph feature works

Property graph over relational tables

In Postgres, a property graph is a read-only view defined over existing relational tables. You configure:

  • Vertex tables for entities
  • Edge tables for relationships, mapped using existing key columns (source/destination)

Querying with graph_table and MATCH

Graph queries are written using:

  • A graph_table function in the FROM clause
  • MATCH patterns to describe graph structure

Key syntax notes:

  • Arrow syntax encodes edge direction
  • Labels/filters select which tables are involved
  • A COLUMNS clause specifies which node/edge properties are returned as normal SQL columns

Integrates with SQL

Graph queries behave like regular SQL in important ways:

  • You can join graph results with regular tables
  • You can use CTEs and other relational constructs

Execution model and security

Implementation-wise:

  • Graph queries are rewritten into relational operations (joins/unions) during planner rewrite
  • They execute as regular SQL using existing indexes
  • Postgres security features still apply, including:
    • access permissions
    • row level security (RLS)

Key limitations / expectations

  • This is not a native graph storage engine.
  • Because execution relies on joins and recursive-style relational planning, you should not expect Neo4j-like constant per-hop traversal cost from index-free adjacency.
  • Initially, only fixed-depth pattern matching is supported:
    • Known-length chains are straightforward
    • True variable-length traversal (e.g., “any number of hops” using operators like *, +, or bounded ranges) is not supported yet and is expected later
  • For workloads where the graph is central and requires large, deep repeated traversals, a native graph database may still be the better choice.

Targeted use cases (good fits)

The feature is positioned as a good fit for:

  • Authorization graphs
  • Dependency graphs
  • Organizational hierarchies
  • Product relationship queries
  • Recommendation pre-filtering
  • Customer ↔ account/device link analysis
  • Audit / fraud investigation queries, especially when traversal depth is not arbitrary/unknown

Standards and competing approaches

Standardization

The syntax isn’t purely Postgres-specific:

  • It was formalized by ISO in 2023, defining:
    • GQL (standalone graph language)
    • SQL/PGQ (graph pattern matching embedded in SQL-like syntax)

Other vendors

  • Oracle shipped SQL/PGQ in 23AI
  • DDB provides similar functionality via an extension

Historical workaround in Postgres

For roughly the last 15 years, graph traversal could be approximated using Postgres features like:

  • CTEs with WITH RECURSIVE

That approach is described as messy and difficult to optimize/debug—so this feature is presented as a cleaner, more declarative alternative.

Included trivia / real-world example (Neo4j + investigative journalism)

A trivia segment highlights the International Consortium of Investigative Journalists (ICIJ) using Neo4j for analysis related to the Panama Papers:

  • They processed ~11.5 million documents
  • They used document processing and search tooling:
    • Apache Tika (text/metadata extraction)
    • Tesseract (OCR)
    • Apache Solr + Blacklight (search UI with advanced querying like proximity/regex)
  • After extracting structured entities/relationships, Neo4j was used to model and query the connections.

Main speakers / sources

  • Speaker: Unspecified (video narrator/author; references “me” when discussing community/next video)
  • Sources mentioned: Postgres 19, ISO (2023 ISO committee), Neo4j, Oracle, DDB, and ICIJ / Panama Papers (from the trivia segment)

Original video