DuckDB has long stood out among analytical databases for its speed on complex queries run directly in process. Now a community extension called DuckPGQ lets users query relational data as property graphs without leaving the familiar SQL environment. The project implements the SQL/PGQ standard approved in SQL:2023. Analysts gain pattern matching and path finding tools that once required separate graph systems.
Installation takes two commands. Run INSTALL duckpgq FROM community; followed by LOAD duckpgq;. The extension appeared first as a research prototype from CWI in Amsterdam. Daniël ten Wolde, a PhD student there, leads development. He presented early results at the 19th LDBC TUC meeting. Downloads reached 15,000 by early 2025 with a weekly peak of 3,100. A fix for DuckDB 1.5.0 addressed a bug that reported missing “csr_cte” in some graph functions. The project remains a work in progress. Users report bugs through the repository.
Property graphs sit as a transient layer over existing tables. The syntax CREATE PROPERTY GRAPH declares vertex tables and edge tables with source and destination keys. One recent DuckDB blog post demonstrates this on the LDBC Financial Benchmark. The example loads 785 persons, 2,055 accounts and 8,132 transfers. The graph definition maps PersonOwnAccount edges labeled PersonOwn and AccountTransferAccount edges labeled Transfer.
Queries use the GRAPH_TABLE function with a MATCH clause that borrows visual notation from Cypher. Short fragments such as (a:Account)-[t:Transfer]->(a2:Account) read naturally. Aggregations follow in ordinary SQL. The same post shows a search for smurfing patterns. It counts transfers between accounts where average amount stays under $50,000. Results revealed no clear cases in the sample data. Yet the query ran without exporting tables to another store.
Path queries expose greater power. The post finds cycles that return money to accounts owned by the same person. The pattern (p:Person)-[o1:PersonOwn]->(a1:Account)-[t:Transfer]->+(a2:Account)<-[o2:PersonOwn]-(p:Person) combined with ANY SHORTEST and a WHERE clause on person ID returns paths of length eight to twelve. Traditional joins would demand recursive common table expressions that grow unwieldy. SQL/PGQ keeps the logic compact.
Performance matters. ArcadeDB's benchmark page from April 2026 places DuckPGQ on a PageRank test at 6.14 seconds. That trails ArcadeDB at 0.48 seconds and Kuzu at 4.30 seconds yet beats Memgraph at 16.90 seconds and ArangoDB at 157.01 seconds. On connected components DuckPGQ took 13.93 seconds against ArcadeDB's 0.30 seconds. Breadth-first search showed 2,754 seconds, far slower than leaders. These numbers reflect a single dataset. Real workloads vary.
A master's thesis completed in 2024 at CWI pushed improvements. Pingan Ren, supervised by Peter Boncz and daily guidance from ten Wolde, refactored multi-source breadth-first search. The new parallel operator replaced a user-defined function approach that could not exploit all cores. Experiments on LDBC SNB scale factor 300 delivered up to 11.46 times speedup for shortest path finding with 4,096 pairs. Speedup flattened beyond four threads because of synchronization overhead, memory bandwidth limits and cache misses. Direction optimization added little value for multi-source cases. The work proved the operator integration brought measurable gains on large sparse graphs. Bottlenecks remain. Future directions listed in the thesis include SIMD, better workload elimination and distributed execution.
Researchers continue to cite DuckPGQ. A May 2025 survey on graph databases references it alongside other systems that adopt SQL/PGQ. A 2025 VLDB Journal article on navigational query optimization notes difficulties running DuckPGQ during experiments yet acknowledges its role in the analytical RDBMS category. An academic paper on parallel path finding credits the extension's CSR construction as the foundation for custom operators.
Practical projects have appeared. Sixing Huang released DuckGraphViz in 2025 to visualize results from DuckPGQ queries using a Neo4j library. One example explores a drug knowledge graph with more than 5,500 substances. A May 2026 blog compared DuckPGQ on baseball data against LadybugDB, the successor to Kuzu, and PostgreSQL. DuckPGQ handled the 5.6 million row dataset but showed compatibility limits with the newest DuckDB patch versions. Extensions are built only for specific releases. Users must sometimes stay on 1.4.4 or 1.5.0.
Financial crime detection stands out as a natural fit. The DuckDB post walks through detection of cycles that could mask laundering. It stresses that the same database already holds the transactional tables. No data movement is required. The extension therefore reduces operational friction. Teams avoid standing up Neo4j or Memgraph for occasional graph work. Yet native graph stores still win on latency for highly iterative traversals. DuckPGQ targets analytical batches where columnar storage and vectorized execution shine.
Adoption chatter on X remains modest but steady. Recent posts mention pairing DuckPGQ with LanceDB for multimodal graphs or testing it on unknown JSONL schemas. One user asked whether DuckPGQ had caught up to dedicated engines. Another listed it first among non-Java options when recommending tools. Interest appears strongest among data teams already invested in DuckDB's Python, R or JavaScript APIs.
The extension does not persist graphs across connections in early versions. Version 0.1.0 added persistence synchronized between sessions. Algorithms now include PageRank, weakly connected components and shortest paths. Documentation at duckpgq.org lists these functions with examples on synthetic networks and airline routes.
Challenges persist. The project carries a research label. Some queries still expose performance cliffs. Benchmark results show wide gaps against optimized native engines on certain traversals. Integration with DuckDB's morsel-driven scheduler sometimes limits parallelism. Ren's thesis highlighted that custom operators bypass those limits yet introduce their own synchronization costs. Ten Wolde has continued updates. A podcast appearance in March 2025 discussed benchmarks and the road to production machine learning use cases.
Standardization helps. SQL:2023's property graph queries section reduces the gap between relational and native graph systems. Oracle added support in 2023. PostgreSQL and others experiment with similar features. DuckPGQ brings the syntax to an embeddable engine popular in notebooks and data pipelines. Analysts write one query that joins graph patterns with time-series aggregations or spatial filters. The combination feels fresh.
Look ahead. Community contributions could widen the algorithm set. Better visualization tools may arrive. Tighter ties to vector extensions could open hybrid search. For now the extension delivers a practical bridge. Data teams load Parquet files, declare a graph and hunt suspicious loops in the same session. That workflow shrinks the distance between discovery and production. And the numbers keep improving.
WebProNews is an iEntry Publication