DuckPGQ: Graph Analytics di DuckDB dengan SQL & Cypher 2026 — Tanpa Database Tambahan

Untuk sebagian besar use case graph analytics — menemukan shortest path antar node, mendeteksi komunitas, menghitung PageRank, menelusuri multi-hop relationship — pendekatan tradisional memerlukan database graph khusus seperti Neo4j atau TigerGraph. Database ini powerful, tetapi juga membawa overhead operasional yang signifikan untuk workload yang bersifat analitis dan batch. DuckPGQ, yang merupakan extension resmi DuckDB untuk property graph queries, menawarkan paradigma yang berbeda: graph analytics langsung di DuckDB, dengan SQL/PGQ dan Cypher-style syntax, tanpa menambah komponen database baru.

Artikel ini membahas apa yang DuckPGQ sediakan, bagaimana cara menggunakannya untuk use case nyata, dan trade-off yang harus dipahami sebelum memilihnya di atas database graph tradisional.

Konteks: DuckDB sebagai Analytical Engine

DuckDB telah memantapkan dirinya sebagai analytical database untuk workload embedded. Formatnya adalah OLAP-optimized, kolom-natif, dan berjalan sebagai library dalam proses aplikasi — bukan sebagai service terpisah. Ini membuat DuckDB sangat cocok untuk analisis data lokal, notebook, dan pipeline ETL yang tidak memerlukan database server dedicated.

Dengan DuckPGQ, kemampuan DuckDB diperluas ke property graph queries. Properti utama yang dibawa extension ini:

1. SQL/PGQ (Property Graph Queries) — ekstensi SQL standar ISO untuk graph queries, dengan pattern matching syntax yang familiar untuk pengguna SQL
2. Cypher-style queries — subset dari bahasa query Neo4j, untuk pengguna yang lebih suka traversing dengan arrow syntax
3. Integrasi native dengan DuckDB DataFrame — graph queries bisa digabung dengan analytical queries pada tabel relasional
4. Zero-copy operations — bekerja langsung di atas data DuckDB tanpa duplicating

Instalasi dan Setup

DuckPGQ tersedia sebagai binary extension untuk DuckDB. Instalasi cukup sederhana:

# Python
pip install duckdb
python -c "import duckdb; con = duckdb.connect(); con.execute('INSTALL duckpgq; LOAD duckpgq; print("OK")')"

# CLI DuckDB
duckdb -c "INSTALL duckpgq; LOAD duckpgq;"

# DuckDB SQL
INSTALL duckpgq;
LOAD duckpgq;

Setelah extension di-load, DuckDB mengenali sintaks SQL/PGQ. DuckPGQ tidak menyimpan data secara terpisah — extension ini bekerja dengan data yang sudah ada di tabel DuckDB, yang dideklarasikan sebagai node atau edge dari property graph.

Contoh: Jejaring Sosial dengan SQL/PGQ

Misalkan kita memiliki data jejaring sosial dalam dua tabel DuckDB biasa:

CREATE TABLE users (
  user_id BIGINT PRIMARY KEY,
  username TEXT NOT NULL,
  created_at TIMESTAMPTZ
);

CREATE TABLE friendships (
  user_a BIGINT NOT NULL,
  user_b BIGINT NOT NULL,
  since DATE,
  PRIMARY KEY (user_a, user_b)
);

INSERT INTO users VALUES
  (1, 'alice', '2024-01-15'),
  (2, 'bob', '2024-02-20'),
  (3, 'carol', '2024-03-10'),
  (4, 'dave', '2024-03-15'),
  (5, 'eve', '2024-04-22');

INSERT INTO friendships VALUES
  (1, 2, '2024-03-01'),
  (1, 3, '2024-04-15'),
  (2, 4, '2024-05-01'),
  (3, 5, '2024-06-01'),
  (4, 5, '2024-06-15');

Untuk menggunakan SQL/PGQ, kita deklarasikan property graph dari tabel-tabel ini:

CREATE PROPERTY GRAPH social_network
  VERTEX TABLES (
    users PROPERTIES (user_id, username, created_at)
  )
  EDGE TABLES (
    friendships
      SOURCE KEY (user_a) REFERENCES users (user_id)
      DESTINATION KEY (user_b) REFERENCES users (user_id)
      PROPERTIES (since)
  );

Sekarang graph tersedia untuk query. Untuk menemukan semua teman dari teman user 1 (two-hop traversal):

SELECT username, COUNT(*) AS mutual_friends
FROM GRAPH_TABLE(social_network
  MATCH (a IS users)-[IS friendships]->(b IS users)-[IS friendships]->(c IS users)
  WHERE a.user_id = 1 AND c.user_id != 1
  COLUMNS (c.username)
) AS two_hop
GROUP BY username
ORDER BY mutual_friends DESC;

Pattern ini memanfaatkan MATCH clause yang familiar untuk pengguna Neo4j Cypher, tetapi beroperasi di atas tabel DuckDB yang sudah ada. Hasilnya adalah tabel biasa yang bisa digabung dengan analytical queries lebih lanjut.

Contoh: Fraud Detection dengan Path Pattern

Salah satu use case paling kuat untuk graph analytics adalah fraud detection. Pola umum: cari apakah dua user yang seharusnya independen ternyata terhubung melalui chain of accounts yang mencurigakan.

-- Tabel accounts
CREATE TABLE accounts (
  account_id BIGINT PRIMARY KEY,
  holder_name TEXT,
  country TEXT,
  opened_at DATE
);

-- Tabel transfers
CREATE TABLE transfers (
  transfer_id BIGINT PRIMARY KEY,
  from_account BIGINT,
  to_account BIGINT,
  amount NUMERIC(15, 2),
  transferred_at TIMESTAMPTZ
);

CREATE PROPERTY GRAPH financial
  VERTEX TABLES (accounts)
  EDGE TABLES (
    transfers
      SOURCE KEY (from_account) REFERENCES accounts
      DESTINATION KEY (to_account) REFERENCES accounts
      PROPERTIES (amount, transferred_at)
  );

-- Cari chain 3-hop antara dua account
SELECT path, total_amount
FROM GRAPH_TABLE(financial
  MATCH (a)-[t1:transfers]->(b)-[t2:transfers]->(c)-[t3:transfers]->(d)
  WHERE a.account_id = 1001 AND d.account_id = 2002
    AND t1.transferred_at > NOW() - INTERVAL '30 days'
  COLUMNS (
    LIST(t1.transfer_id, t2.transfer_id, t3.transfer_id) AS path,
    t1.amount + t2.amount + t3.amount AS total_amount
  )
);

Query ini menemukan semua path tiga-hop dari account 1001 ke 2002 dalam 30 hari terakhir, dengan total amount. Pola ini sulit diekspresikan dalam SQL biasa (recursive CTE bisa, tetapi dengan overhead penulisan yang lebih besar) dan menjadi natural dengan SQL/PGQ.

Integrasi dengan Python DataFrame

Salah satu kekuatan DuckDB yang paling dihargai adalah interoperabilitasnya dengan Pandas dan Polars. DuckPGQ mempertahankan interoperabilitas ini:

import duckdb
import pandas as pd

con = duckdb.connect()
con.execute("INSTALL duckpgq; LOAD duckpgq;")

# Load data dari DataFrame
users_df = pd.read_parquet("users.parquet")
friends_df = pd.read_parquet("friendships.parquet")

con.register("users", users_df)
con.register("friendships", friends_df)

# Jalankan graph query, hasil kembali sebagai DataFrame
result_df = con.execute(
    "CREATE PROPERTY GRAPH social AS ... "
    "SELECT * FROM GRAPH_TABLE(social MATCH ...)"
).df()

Untuk data scientist yang workflow-nya berbasis notebook atau script Python, ini adalah integrasi yang sangat natural. Tidak perlu ETL ke database graph terpisah — analisis graph berjalan di tempat data sudah berada.

Kapan DuckPGQ Tepat, Kapan Tidak

DuckPGQ bukan pengganti Neo4j atau TigerGraph untuk semua use case. Berikut panduannya:

DuckPGQ tepat untuk:

• Analytical graph queries yang berjalan sebagai batch (bukan real-time transactions)
• Workload yang sudah menggunakan DuckDB untuk analytical queries
• Use case dengan volume data menengah (ratusan juta edge masih manageable)
• Prototyping graph queries sebelum memutuskan apakah perlu database graph khusus
• Pipeline ETL yang menghasilkan graph features untuk model ML

Database graph khusus lebih tepat untuk:

• Workload transaksional tinggi (graph mutations per detik yang tinggi)
• Graph yang sangat besar dengan miliaran edge (meskipun DuckDB bisa, operasi mungkin lebih lambat)
• Real-time traversal queries dengan latency sangat rendah
• Kebutuhan graph algorithms yang lebih lengkap (built-in community detection, centrality measures, ds. versi advanced)
• Operasional multi-user dengan isolation dan access control kompleks

Roadmap dan Ekosistem

DuckPGQ masih dalam pengembangan aktif. Subset Cypher yang didukung adalah bagian yang paling umum, dan coverage SQL/PGQ terus berkembang mengikuti standar ISO. Untuk algorithm suite yang lebih lengkap (PageRank, shortest path, connected components), DuckDB ecosystem sedang menyiapkan extension terpisah yang bekerja dengan DuckPGQ sebagai graph provider.

Komunitas yang mengelilingi DuckDB dan DuckPGQ aktif, dan extension ini memiliki sponsor institusional yang kuat (termasuk hibah dari foundations dan kontribusi dari perusahaan yang menggunakan DuckDB secara internal untuk analytical pipelines). Ini bukan proyek sampingan yang bisa hilang besok — fondasi untuk adopsi serius sudah ada.

Penutup

DuckPGQ menunjukkan arah menarik dalam evolusi analytical database: kemampuan graph analytics sebagai citizen kelas satu, tanpa menambah komponen database baru. Untuk tim yang sudah nyaman dengan DuckDB dan ingin kemampuan graph tanpa overhead operasional Neo4j, DuckPGQ adalah opsi yang sangat menarik untuk dievaluasi. Seperti semua tool, eksplorasi awal dengan data nyata dari use case lo adalah cara terbaik untuk memutuskan apakah ia cocok — dan untungnya, instalasi dan setup-nya cukup ringan untuk memungkinkan eksplorasi itu dilakukan dalam hitungan jam, bukan minggu.

Performance Benchmark: DuckPGQ vs Neo4j pada Workload Realistis

Salah satu pertanyaan yang paling sering muncul saat mengevaluasi DuckPGQ adalah: bagaimana performanya dibandingkan dengan database graph khusus seperti Neo4j untuk workload yang sama? Benchmark yang dilakukan oleh kontributor DuckPGQ dan independen researcher memberikan gambaran yang cukup jelas tentang trade-off.

Pada workload graph traversal dengan pola yang umum (2-hop sampai 4-hop pattern matching), DuckPGQ menunjukkan performa yang sebanding dengan Neo4j untuk dataset hingga ratusan juta edge, terutama ketika query memanfaatkan columnar execution DuckDB. Untuk pattern matching yang kompleks dengan banyak variable binding, DuckPGQ kadang lebih cepat karena optimasi columnar-nya lebih mature.

Di sisi lain, untuk graph algorithms yang memerlukan iterative computation (seperti PageRank, connected components, atau community detection), database graph khusus biasanya unggul karena mereka memiliki implementasi yang dioptimasi secara spesifik untuk algoritma tersebut. DuckPGQ mengandalkan extension terpisah atau implementasi user-defined untuk algoritma semacam itu.

Untuk transaksi graph (graph mutations per detik), database graph seperti Neo4j memiliki keunggulan signifikan karena arsitektur mereka yang memang dirancang untuk write-heavy workloads. DuckDB pada dasarnya adalah OLAP engine yang read-oriented, dan meskipun DuckPGQ extension membuatnya mampu melakukan graph queries, ia tidak ditujukan untuk workload transactional yang intensif.

Pola Penggunaan yang Efektif

Untuk memaksimalkan nilai DuckPGQ dalam workflow analitis, ada beberapa pola yang terbukti efektif berdasarkan pengalaman deployment.

Materialisasi Graph sebagai Tabel Relasional

Untuk dataset yang besar, lebih efisien untuk melakukan materialisasi graph sebagai tabel relasional dengan kolom-kolom yang sudah di-precompute (misalnya adjacency list yang sudah difilter), kemudian menjalankan DuckPGQ queries di atas tabel tersebut. Pendekatan ini memanfaatkan kekuatan DuckDB dalam scanning kolom dan filtering, yang biasanya lebih cepat daripada pattern matching pada graph yang fully expanded.

-- Materialisasi adjacency list untuk analisis friend-of-friend
CREATE TABLE adjacency AS
  SELECT user_a AS source, user_b AS target
  FROM friendships
  UNION ALL
  SELECT user_b, user_a;  -- bidirectional edges

-- Pattern matching pada materialized adjacency
SELECT t1.source, t3.target
FROM adjacency t1
JOIN adjacency t2 ON t1.target = t2.source
JOIN adjacency t3 ON t2.target = t3.source
WHERE t1.source = 1;

SQL biasa dengan JOIN tiga-tahap ini sering kali secepat pattern matching DuckPGQ untuk query yang sederhana, dan memiliki keuntungan bahwa query plan-nya lebih predictable. DuckPGQ unggul ketika pattern matching lebih kompleks (variabel length paths, optional matches, dsb) yang sulit diekspresikan dalam SQL biasa.

Incremental Updates dengan Versioning

Untuk use case di mana graph sering berubah (misalnya social network dengan edges baru setiap hari), pattern yang efektif adalah melakukan versioning pada graph dan menjalankan query pada snapshot tertentu. DuckDB mendukung time travel queries yang memungkinkan ini secara natural.

-- Query pada snapshot tertentu
SELECT * FROM GRAPH_TABLE(social_network
  MATCH (a)-[r]->(b)
  WHERE r.valid_from <= '2026-07-25' AND r.valid_to > '2026-07-25'
  COLUMNS (a.username, b.username)
);

Pola ini memungkinkan analisis historis tanpa perlu me-rebuild graph untuk setiap query. Untuk audit trail atau analisis trend, ini sangat powerful.

Komunitas dan Kontribusi

DuckPGQ dikembangkan secara terbuka dengan kontribusi dari berbagai pihak — akademisi, engineer industri, dan kontributor independen. Repository GitHub extension ini aktif, dengan issue tracker yang responsif dan roadmap yang transparan. Diskusi pengembangan terjadi di Discord DuckDB dan forum resmi, dengan maintainer yang aktif menjawab pertanyaan.

Untuk developer yang ingin berkontribusi, area yang paling banyak membutuhkan bantuan adalah: dokumentasi (terutama untuk use case advanced), test coverage (khususnya untuk edge cases pattern matching), dan integrasi dengan tools ekosistem Python (misalnya adapter untuk NetworkX, integrasi yang lebih dalam dengan Pandas). Berkontribusi ke proyek seperti DuckPGQ tidak hanya memberikan dampak pada ekosistem open source, tetapi juga merupakan cara yang sangat efektif untuk memperdalam pemahaman tentang graph database dan query optimization.

Penutup dan Outlook

DuckPGQ adalah salah satu eksperimen paling menarik di ruang analytical database saat ini. Dengan menggabungkan kekuatan DuckDB untuk analytical workloads dengan kemampuan graph queries yang sebelumnya hanya ada di database khusus, ia menawarkan paradigma baru untuk analisis data yang kompleks. Apakah ia akan menggantikan database graph tradisional untuk use case tertentu masih harus dibuktikan oleh waktu, tetapi sebagai tools untuk eksplorasi dan prototyping, ia sudah cukup matang untuk diadopsi.

Untuk profesional data yang sering bergulat dengan trade-off antara tooling yang sederhana dan kemampuan yang powerful, DuckPGQ adalah reminder bahwa evolusi tooling data masih sangat aktif. Library yang sebelumnya membutuhkan setup khusus dan operasional yang berat sekarang dapat diakses sebagai extension dari database yang sudah umum. Ini adalah trend yang sehat untuk ekosistem data secara keseluruhan — lebih banyak pilihan, lebih sedikit lock-in, dan lebih banyak fleksibilitas untuk memilih tooling yang sesuai dengan kebutuhan spesifik.