"DuckPGQ Brings SQL-Standard Graph Queries to DuckDB, No Neo4j Required"

Graph databases have spent the last decade convincing developers that they need a whole new query language — Cypher, Gremlin, SPARQL — to work with connected data. DuckPGQ, a community extension for DuckDB that just hit the community extension registry, takes the opposite bet: what if you could just use SQL?

DuckPGQ implements the SQL/PGQ standard from SQL:2023, which ISO quietly ratified as the official way to query property graphs within a relational database. The extension lets you define a property graph over your existing DuckDB tables — no ETL, no graph-specific storage engine — and then run path queries and pattern matching with new SQL syntax like MATCH and SHORTEST_PATH. It installs with a single INSTALL duckpgq FROM community and requires zero external dependencies.

The academic lineage here is worth paying attention to. DuckPGQ comes out of CWI's Database Architectures group — the same Amsterdam lab that created DuckDB itself, and the same group that produced MonetDB before it. They published the DuckPGQ design at VLDB 2023 and a performance paper at CIDR 2023, which found that on large graph datasets the extension delivers "encouraging performance and scalability" while noting that columnar storage and graph traversal remain an awkward match. That honesty is refreshing: the paper explicitly calls out areas where research is still needed rather than pretending columnar graphs are a solved problem.

What's clever about the SQL/PGQ approach is that it treats the graph as a view over your existing relational data, not a separate system you have to mirror into. You define which tables map to vertices and edges with a CREATE PROPERTY GRAPH statement, and DuckPGQ builds the necessary in-memory structures on the fly when you query. There's no graph-native storage format to manage, no dual-write consistency problem, and no second query language to learn — just SQL with a few new clauses.

This matters more than it might seem. The analytics world has already settled on DuckDB as the go-to for fast, local analytical queries (it ships inside browsers via WASM, powers dashboard tools like MotherDuck, and shows up in everything from Python notebooks to R pipelines). Adding graph capabilities to that same runtime means a data analyst who needs to answer "find the shortest connection between these two accounts in the transaction graph" doesn't have to spin up a Neo4j instance or learn Cypher. They stay in the same notebook, same SQL dialect, same toolchain.

There's a broader trend here worth watching. SQL:2023 didn't just add graph queries — it also introduced property graph data types and graph pattern matching as first-class concepts. PostgreSQL already has Apache AGE for Cypher-compatible graph queries; now DuckDB has SQL/PGQ. If graph queries become just another SQL feature that every database ships, the stand-alone graph database category starts looking less like a permanent niche and more like a transitional phase — the way full-text search engines mostly got absorbed into general-purpose databases a decade ago.

That said, DuckPGQ is explicitly labeled as a work in progress in its own documentation. It doesn't yet support writes to graph structures, and the performance characteristics on genuinely massive graphs (think billions of edges with deep recursive traversals) are an open research question. The team is transparent about these limits, which is the right posture for a research project in active development. For the common analytical case — "give me paths through this modestly-sized graph, I'm in a Jupyter notebook and I want results in seconds" — it already delivers.

One practical detail worth knowing: the extension is available in DuckDB's community extension repository, not the core extension set. That means it gets the same security review as any community contribution, but it won't ship automatically with DuckDB installs. You have to explicitly opt in. For a tool that analysts might use on production financial or healthcare graph data, that's probably the right default — trust, but install explicitly.

This is one of those quiet infrastructure improvements that won't make headlines but will genuinely make data work easier for a lot of people. Ten years ago, doing spatial queries in a database meant installing PostGIS and learning a whole geometry dialect. Today ST_Distance is just SQL. DuckPGQ points toward a similar future for graphs — and given DuckDB's momentum, it's a bet worth tracking.

Sources: DuckPGQ homepage, DuckPGQ on GitHub, DuckPGQ: Efficient Property Graph Queries in an analytical RDBMS (CIDR 2023), DuckPGQ: Bringing SQL/PGQ to DuckDB (VLDB 2023)