DuckDB: Analitik OLAP In-Process di Parquet, CSV, dan S3

Kebanyakan pertanyaan analitik yang saya terima sifatnya sekali pakai dan merepotkan: seorang stakeholder menaruh folder berisi ekspor Parquet dan ingin total per grup selesai hari Jumat. Jawaban tradisionalnya adalah menyiapkan warehouse, mendefinisikan skema, menulis job ingesti, dan memuat data sebelum bisa menjalankan satu agregat pun. Untuk pertanyaan yang butuh sepuluh detik SQL, beban kerja itu berlebihan.

DuckDB adalah alat yang menghilangkan beban itu bagi saya. Ia adalah database analitik in-process yang dirilis dengan lisensi permisif MIT, dan cara termudah menggambarkannya adalah SQLite untuk analitik: tanpa server, tanpa daemon, tanpa lompatan jaringan. Anda menambahkan satu pustaka ke proses Anda dan langsung punya mesin SQL penuh yang membaca data kolumnar dengan cepat. Ia mencapai versi stabil 1.0.0 pada 3 Juni 2024, jadi format penyimpanan dan API-nya kini aman untuk dijadikan fondasi.

In-process, kolumnar, dan vektorisasi

Dua keputusan desain membuat DuckDB cepat untuk kueri yang benar-benar dijalankan analis. Pertama, ia kolumnar: menyimpan dan membaca data satu kolom pada satu waktu, sehingga kueri yang menyentuh tiga kolom dari tabel lima puluh kolom hanya membayar tiga kolom itu. Database berbasis baris seperti SQLite atau tabel Postgres bawaan membaca seluruh baris dari disk meski Anda hanya minta sebagian kecil. Untuk pemindaian dan agregat pada tabel besar, selisih itu sangat besar.

Kedua, DuckDB memakai mesin eksekusi vektorisasi. Alih-alih mendorong baris melewati operator kueri satu per satu, ia memprosesnya dalam batch berisi beberapa ribu nilai yang muat di cache CPU, sehingga memangkas overhead per baris yang mendominasi mesin tradisional. Sifat in-process juga penting: kueri berjalan di dalam proses Python atau Node Anda, jadi hasil tidak pernah melintasi soket. Tidak ada server yang perlu dipasang, diperbarui, atau dirawat.

Kueri file secara langsung — tanpa ETL, tanpa skema

Fitur yang mengubah cara kerja saya adalah DuckDB mengkueri file di tempatnya berada. File berakhiran .parquet bisa langsung masuk ke klausa FROM, dan read_csv atau read_json_auto melakukan hal sama untuk format lain, dengan menyimpulkan tipe data secara otomatis. Pola glob memperlakukan seluruh folder file sebagai satu tabel. Tidak ada CREATE TABLE, tidak ada COPY, tidak ada langkah pemuatan sama sekali — file itulah tabelnya.

-- No load step, no schema, no server. Just point SQL at the file.
SELECT country, COUNT(*) AS orders, SUM(amount) AS revenue
FROM 'sales/2026-*.parquet'
WHERE status = 'paid'
GROUP BY country
ORDER BY revenue DESC
LIMIT 10;

-- CSV and JSON work the same way, with types inferred automatically.
SELECT * FROM read_csv('events.csv');
SELECT * FROM read_json_auto('logs.json');

Jangkau lintas jaringan — data remote dan S3

Ekstensi httpfs memperluas model ini ke penyimpanan remote. Setelah satu baris INSTALL dan LOAD, Anda bisa mengarahkan read_parquet ke URL https:// atau jalur s3:// dan DuckDB hanya mengalirkan rentang byte yang diperlukan alih-alih mengunduh seluruh objek. Kredensial disimpan dalam secret yang dibuat dengan CREATE SECRET, atau Anda bisa mengandalkan rantai kredensial AWS standar. Ini mengubah data lake S3 menjadi sesuatu yang bisa Anda kueri dari laptop dengan SQL biasa.

INSTALL httpfs;
LOAD httpfs;

-- Store credentials once as a secret (or use the AWS credential chain).
CREATE SECRET (
  TYPE s3,
  KEY_ID 'AKIAIOSFODNN7EXAMPLE',
  SECRET 'wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY',
  REGION 'us-east-1'
);

-- Query a remote Parquet file directly; only the needed bytes are fetched.
SELECT device, AVG(latency_ms) AS p_latency
FROM read_parquet('s3://my-bucket/metrics/*.parquet')
GROUP BY device;

Tanamkan di mana saja — Python, Node, dan browser

Karena DuckDB terkompilasi menjadi satu header dan satu file implementasi tanpa dependensi eksternal, ia bisa masuk ke hampir semua runtime. Klien Python dan R menjadikannya pilihan default untuk analitik di notebook; klien Node.js resmi hadir sebagai paket @duckdb/node-api dengan dukungan Promise native, memungkinkan backend menjalankan SQL analitik tanpa layanan database terpisah. Mesin yang sama juga menggerakkan klien command-line dan JVM.

Klien yang paling mengejutkan orang adalah DuckDB-Wasm. DuckDB telah dikompilasi ke WebAssembly, sehingga mesin penuhnya berjalan di dalam browser apa pun di perangkat apa pun — tanpa backend. Sebuah dashboard bisa mengambil file Parquet dan membiarkan pengguna melakukan pivot, filter, dan agregat sepenuhnya di sisi klien, itulah cara alat seperti penjelajah data interaktif menyajikan analitik tanpa biaya server. Kompromi-nya adalah satu thread dan batas memori sekitar empat gigabyte.

DuckDB versus SQLite versus Postgres

Mudah salah mengira DuckDB sebagai pengganti langsung database yang sudah Anda jalankan. Ia bukan itu — ia menargetkan beban kerja yang berbeda. Tabel ini menjabarkan di mana masing-masing cocok agar Anda memilih berdasarkan bentuk kueri, bukan kebiasaan.

Kapan memilih DuckDB dibanding Postgres atau warehouse

Aturan praktis saya adalah mencocokkan alat dengan beban kerja, bukan dengan ukuran data. DuckDB layak dipakai saat kuerinya analitik dan deployment-nya satu node. Pilih ia ketika:

• Anda perlu menjalankan agregat ad-hoc pada file Parquet, CSV, atau JSON tanpa menyiapkan infrastruktur apa pun lebih dulu.
• Analitik Anda muat nyaman di satu mesin — DuckDB menangani dataset jauh lebih besar dari RAM dengan spill ke disk, jadi ini mencakup banyak kasus.
• Anda ingin mendorong analitik ke dalam notebook, job backend, atau browser tanpa mengoperasikan server database terpisah.
• Anda membuat prototipe transformasi terhadap data lake dan menginginkan SQL bergaya warehouse tanpa biaya atau latensi bergaya warehouse.

Tetap gunakan Postgres saat Anda butuh banyak penulis serentak, integritas transaksional, dan database bersama berumur panjang di belakang sebuah aplikasi. Pakai cloud warehouse seperti BigQuery atau Snowflake saat analitik harus berskala lintas banyak node atau dibagikan ke seluruh organisasi sekaligus. DuckDB mengisi celah lebar di antaranya, dan untuk analitik sehari-hari yang saya jalankan, celah itulah tempat sebagian besar pekerjaan sebenarnya berada.