If you've ever written a recursive CTE in PostgreSQL, you probably remember two things:

1. It worked.
2. You never wanted to touch it again.

Whether you're dealing with organization hierarchies, authorization models, dependency trees, or fraud detection, relational databases have always been capable of handling graph-like data—but the SQL wasn't exactly enjoyable.

That's changing with PostgreSQL 19 Beta.

Meet SQL/PGQ

PostgreSQL 19 introduces SQL/PGQ (Property Graph Queries), an ISO-standard way to query graph-shaped data directly inside PostgreSQL.

Instead of moving your data into a graph database, you define a property graph on top of your existing relational tables.

Think of it as a graph view built from tables you already have.

Once defined, you can query relationships using graph patterns instead of complicated recursive SQL.

What's happening behind the scenes?

One detail I found particularly interesting is that PostgreSQL isn't becoming a native graph database.

Graph queries are rewritten into regular SQL joins before execution.

That means:

• Existing indexes continue to work.
• Row-level security still applies.
• No new storage engine is required.
• Existing tooling doesn't change.

It's a very PostgreSQL approach—adding new capabilities without changing the core architecture.

Does this replace Neo4j?

Not really.

Native graph databases still have a major advantage when it comes to deep or variable-length graph traversals over massive datasets.

PostgreSQL's implementation is designed for applications where graph relationships complement relational data—not replace it.

In other words:

Use SQL/PGQ when your application is mostly relational with some graph problems.

Use a graph database when your application is fundamentally graph-first.

Where I think this will shine

I can see SQL/PGQ being useful for:

• Authorization and permission graphs
• Organization hierarchies
• Dependency management
• Recommendation relationships
• Fraud investigation
• Network analysis

These are all scenarios where developers often end up writing recursive CTEs today.

My biggest takeaway

I don't think PostgreSQL is trying to compete with Neo4j.

I think it's competing with the awkward SQL we've been writing for years.

For many backend developers, that's a much bigger win.

Will SQL/PGQ solve every graph problem?

No.

But if it helps us replace pages of recursive CTEs with cleaner, more expressive queries, PostgreSQL 19 will be an exciting release to watch.

What do you think? Is SQL/PGQ something you'd adopt, or would you still reach for a dedicated graph database?