Mengapa DuckDB menjadi pilihan pertama saya untuk pemrosesan data

 (robinlinacre.com)
30 poin oleh GN⁺ 2026-01-18 | 2 komentar | Bagikan ke WhatsApp
  • DuckDB adalah mesin SQL open source yang dapat memproses data tabel besar di satu mesin dengan cepat dan sederhana, dan belakangan ini banyak digunakan dalam data engineering
  • Instalasinya sederhana dan tanpa dependensi, serta bisa langsung dijalankan di lingkungan Python sehingga cocok untuk CI dan otomatisasi pengujian
  • Berkat optimasi kueri analitis, performanya bisa hingga 1.000 kali lebih cepat daripada SQLite atau Postgres, dan dapat langsung mengueri berbagai format file (csv, parquet, json)
  • Dengan sintaks SQL yang ramah (EXCLUDE, COLUMNS, QUALIFY, function chaining, dll.) serta Python API, pipeline yang kompleks bisa dikembangkan dengan efisien
  • Dengan kepatuhan ACID, UDF berperforma tinggi, dan ekstensi integrasi PostgreSQL, DuckDB sedang muncul sebagai alternatif lakehouse untuk data skala menengah

Gambaran umum DuckDB

  • DuckDB adalah mesin SQL in-process yang berfokus pada optimasi kueri analitik
    • Berjalan di dalam aplikasi tanpa server terpisah, sehingga tidak memerlukan layanan eksternal seperti Postgres
    • Dioptimalkan untuk operasi join dan agregasi dalam jumlah besar, dan dapat memberikan performa hingga 100~1.000 kali lebih cepat dibanding mesin yang berpusat pada transaksi (OLTP)
  • Kasus penggunaan utamanya adalah batch processing dengan membaca langsung file besar seperti csv, parquet, json dari disk
  • Juga dapat digunakan untuk eksplorasi data ringan, misalnya melihat isi file CSV langsung dari command line

Fitur utama

  • Kecepatan

    • DuckDB adalah salah satu mesin pemrosesan data open source tercepat dan konsisten berada di jajaran atas pada benchmark
    • Dibandingkan dengan Polars, DataFusion, Spark, Dask, dll., DuckDB unggul pada data berukuran kecil, sementara Spark dan Dask kompetitif pada data berukuran besar

  • Instalasi sederhana dan tanpa dependensi

    • DuckDB disediakan dalam bentuk binary pra-kompilasi tunggal, dan di Python bisa langsung dipasang dengan pip install duckdb
    • Karena tanpa dependensi, instalasinya jauh lebih sederhana dibanding framework besar seperti Spark
    • Jika dipadukan dengan uv, lingkungan Python dapat disiapkan dalam kurang dari 1 detik

  • CI dan pengujian

    • Berkat waktu startup yang cepat dan sifatnya yang ringan, DuckDB cocok untuk lingkungan CI dan pengujian pipeline data
    • Pengujian berbasis Spark di masa lalu lambat dan kompleks, tetapi DuckDB memudahkan penyederhanaan setup lingkungan serta menjaga konsistensi dengan produksi

  • Pengalaman menulis SQL

    • DuckDB memungkinkan penulisan SQL dan validasi sintaks dilakukan dengan cepat
    • Lebih unggul untuk eksekusi langsung dan pengembangan iteratif dibanding Spark local mode atau AWS Athena
    • Menyediakan UI dengan fitur autocomplete

  • Sintaks SQL yang ramah

    • DuckDB menyertakan banyak ekstensi SQL yang ramah pengguna
      • Mendukung EXCLUDE, COLUMNS, QUALIFY, modifier agregasi window function, function chaining (first_name.lower().trim()), dan lainnya
    • Fitur-fitur ini membuat pemilihan dan transformasi kolom yang kompleks menjadi lebih ringkas

  • Dukungan berbagai format file

    • Data bisa langsung dikueri dari S3, URL web, atau file lokal
    • Menyediakan opsi ketat untuk tipe CSV guna mencegah error akibat data input yang tidak terstruktur

  • Python API

    • Di Python, pipeline berbasis CTE dapat didefinisikan langkah demi langkah, dan data di tiap tahap dapat diperiksa dengan mudah
      • Hubungkan SQL dalam bentuk chain melalui pemanggilan duckdb.sql()
      • Dengan lazy execution, hasil antara dapat diperiksa tanpa kehilangan performa
    • Fungsi pada setiap tahap bisa diuji sehingga efisiensi pengujian CI meningkat

  • Kepatuhan ACID

    • DuckDB memberikan jaminan ACID penuh bahkan untuk pekerjaan data berukuran besar
    • Karena karakteristik ini, DuckDB bisa dimanfaatkan sebagai pengganti skala menengah untuk format lakehouse seperti Iceberg dan Delta Lake

  • UDF berperforma tinggi dan ekstensi komunitas

    • User-defined function (UDF) berperforma tinggi dapat ditulis dalam C++
    • Melalui Community Extensions, ekstensi dapat langsung dipasang dengan perintah seperti INSTALL h3 FROM community
      • Contoh: dukungan hexagonal indexing (h3) untuk data geospasial

  • Dokumentasi

    • Seluruh dokumentasi disediakan dalam satu file Markdown, sehingga memudahkan pelatihan LLM atau pencarian di editor kode
    • Dengan fitur code folding, hanya bagian yang diperlukan dapat disalin dengan mudah

Pemanfaatan nyata dan dampaknya

  • Pada proyek open source Splink, setelah DuckDB diadopsi sebagai backend default
    • Berhasil mencapai berkurangnya masalah pengguna, peningkatan kecepatan kerja, serta penyederhanaan pengembangan dan pengujian fitur

Ekstensi yang patut diperhatikan

  • PostgreSQL Extension: memungkinkan DuckDB terhubung langsung ke database Postgres dan menjalankan kueri
  • pg_duckdb: menyematkan mesin DuckDB di dalam Postgres sehingga pemrosesan transaksi dan analitik dapat berjalan bersamaan
    • Ke depannya, setelah optimasi indeks Postgres dan peningkatan filter pushup, ada potensi adopsi luas

Bacaan terkait

2 komentar

 
kaydash 2026-01-18

Agak ironis ya, menggunakan parq yang dibuat untuk pemrosesan terdistribusi dengan tujuan diproses di satu mesin saja.
 
GN⁺ 2026-01-18
Komentar Hacker News

  • Ada banyak alasan kenapa saya menyukai DuckDB
    Mendukung file .parquet, .json, dan .csv, serta bisa melakukan pembacaan glob seperti select * from 'tsa20*.csv' sehingga ratusan file bisa diperlakukan seperti satu kesatuan
    Meski skemanya berbeda, file-file itu bisa digabung dengan mudah memakai union_by_name, dan parser CSV-nya juga sangat baik dalam menentukan tipe secara otomatis
    Versi WebAssembly hanya 2MB, CLI-nya 16MB, jadi sangat kecil
    Karena itu, ia bisa langsung dibundel ke dalam produk. Contohnya seperti Malloy
    Malloy seperti versi untuk kalangan teknis dari PowerBI atau Tableau, tetapi memakai model semantik untuk membantu AI menulis kueri yang lebih baik. Rasanya seperti membuat SQL 10 kali lebih mudah ditulis

    • Berkat dukungan CSV DuckDB, cara saya mengeksplorasi data berubah total
      Dulu saya menghabiskan waktu untuk memahami skema terlebih dahulu, tetapi sekarang saya langsung memuat data, menulis kueri eksplorasi, memverifikasi asumsi, lalu mengulangi proses pembersihan, transformasi, dan pembuatan tabel
      Hasilnya, saya bisa menggali jauh lebih cepat dan juga lebih cepat menemukan jalan buntu, sehingga mengurangi pemborosan waktu
      Saya pernah dengar ada makalah yang membahas cara kerja parser CSV ini dan ide peningkatan ke depannya, tapi saya belum menemukannya
    • Belakangan saya banyak memakai ClickHouse, dan ada banyak kelebihan yang mirip dengan DuckDB
      Khususnya ingestion Parquet dan JSON yang nyaman, dan clickhouse-local mirip dengan konsep menanamkan DuckDB
      Dengan sintaks SELECT ... FROM s3Cluster(...), kita bisa melakukan ingest wildcard dari bucket S3, lalu diproses terdistribusi ke node cluster
      Sepertinya juga mendukung schema_inference_mode
      ClickHouse juga sudah mengimplementasikan fitur yang mirip union_by_name
      Dokumentasi terkait: fungsi s3Cluster, schema inference, PR #55892
    • Saya membuat Shaper, yang menggabungkan kueri data dan visualisasi seperti ide Malloy
      Bedanya, Shaper memakai SQL alih-alih bahasa terpisah
      Dengan basis DuckDB, kita bisa membuat dashboard hanya dengan SQL
      Shaper GitHub
    • Saya membuat ZenQuery dan memakai DuckDB untuk pemrosesan internal
      Kecepatannya luar biasa, dan deteksi skema otomatis-nya bekerja akurat hampir sepanjang waktu
      LLM juga bisa menghasilkan SQL yang benar dari kueri bahasa alami
    • Ini benar-benar pengantar yang sangat bagus
      Saya dulu mengimpor manual dengan SQLite, tetapi dengan DuckDB semuanya jadi jauh lebih sederhana

  • Saya juga termasuk orang yang sering memakai DuckDB
    Saya bekerja bersama para ilmuwan yang meneliti lingkungan pesisir BC, menangani data dalam jumlah besar mulai dari pengamatan gletser hingga data drone laut dalam
    Kami mengadopsi DuckDB sebagai mesin untuk alat transformasi data keanekaragaman hayati yang baru, dengan tujuan mengonversi dan memvalidasi data ke standar Darwin Core
    Kami membuat tabel DuckDB secara dinamis berdasarkan skema lalu mengimpor data. Jika gagal, alasannya ditampilkan per baris
    Transformasi dan validasi juga semuanya dijalankan di dalam DuckDB
    Hasilnya, kami bisa membuat aplikasi yang jauh lebih cepat, lebih kuat, dan bahkan bisa berjalan di browser
    Peneliti lapangan bahkan bisa memakainya secara offline di browser iPad
    Berkat DuckDB, ada rasa percaya bahwa SQL menangani pekerjaan beratnya
    Kekurangan dalam type safety kami tutupi dengan parsing dan pengujian
    Tujuan proyek ini adalah agar para ilmuwan bisa menganalisis data keanekaragaman hayati dan genomik dengan alat bersama lalu menerbitkannya ke repositori publik

    • Saya penasaran dataset yang sudah ada itu berformat apa
      Dalam pemrosesan data ilmiah, saya sering menangani HDF5, tetapi DuckDB tidak mendukung HDF5 secara bawaan
      Ekstensi yang ada lambat dan fiturnya kurang, jadi saya membuat ekstensi baru dengan template C++
      Saya sedang mencari orang yang tertarik berkolaborasi
    • Saya penasaran apa kelebihan memakai Polars untuk pekerjaan yang sama
      Secara pribadi saya merasa sintaks Polars jauh lebih nyaman daripada SQL, jadi saya masih menimbang apakah DuckDB layak dicoba

  • Kami menjalankan analitik dan pemrosesan feed Bluesky dengan DuckDB
    Untuk mendapatkan hasil dengan cepat, kami memakai antarmuka Apache Arrow, dan dengan SQG kami menghasilkan kode langsung dari kueri SQL DuckDB

    • Saya penasaran dengan stack teknisnya. Ingin tahu apakah ada tulisan yang membahas arsitektur internalnya. Alat HN-nya juga mengesankan

  • Saya ingin memperkenalkan proyek Java manifold-sql
    Ini memungkinkan penulisan SQL DuckDB secara inline dengan type-safe
    SQL bisa ditaruh langsung di dalam kode dan hasilnya bisa diiterasi lewat .fetch(), jadi rapi tanpa lapisan perantara

  • Klaim penulis masuk akal untuk pemrosesan data dasar,
    tetapi bagian “sebagian besar data tabular bisa diproses di satu mesin” masih bisa diperdebatkan
    Saat melakukan perluasan data, pivot, atau augmentasi, kehabisan memori (OOM) bisa terjadi dengan cepat
    Selain itu, klaim bahwa “SQL harus menjadi pilihan pertama baru untuk data engineering” juga kurang cocok untuk analisis yang kompleks

    • Saya penulis aslinya
      API dataframe seperti Polars atau pandas memang punya banyak kelebihan, tetapi masalahnya ekosistemnya tidak terstandardisasi sehingga pipeline sering harus ditulis ulang
      Sebagian besar data ukurannya di bawah 10GB, jadi satu mesin biasanya sudah cukup
      Banyak kasus yang terlalu berlebihan memakai Spark
      Posisi saya adalah “cobalah DuckDB dulu”. Untuk kasus sederhana, ia cepat dan efisien
    • Untuk analisis tingkat lanjut seperti ML atau visualisasi, dataframe memang lebih cocok
      Untuk pipeline sederhana, SQL bagus, tetapi soal keterbacaan berbeda-beda tergantung orangnya
      Bagi saya, pendekatan dataframe jauh lebih mudah dibaca
    • SQL tetap mudah dipelajari, dan sebagian besar pemodelan data dilakukan dengan SQL
      Di sisi ingestion memang banyak Python atau Scala, tetapi SQL tidak akan hilang
    • Saya memproses 500GB data Parquet dengan DuckDB, dan di desktop dengan RAM 50GB pun tetap lancar dan cepat
      OOM tampaknya hanya akan jadi masalah pada kasus yang ekstrem
    • Polars juga punya sebagian besar kelebihan ini, bahkan mendukung backend GPU dan terdistribusi
      Saat DuckDB mendapat banyak perhatian, Polars justru terkesan diremehkan

  • Saya banyak melakukan pemrosesan data, dan biasanya memakai Polars
    Sangat cepat, dan seperti pandas, punya banyak fungsi yang sulit diimplementasikan dengan SQL
    Fungsi Python juga bisa langsung dipakai
    Walaupun performa DuckDB sama, saya masih ragu karena sepertinya SQL punya batasan dalam ekspresi

    • Dalam pengalaman saya, DuckDB jauh lebih cepat dan ringkas
      Karena berdiri sendiri, instalasinya juga mudah, dan hampir tidak ada tuning maupun learning curve

  • Saya memuat file Excel berformat kacau yang dihasilkan mainframe ke DuckDB,
    dan dengan opsi all_varchar, file itu termuat dalam waktu kurang dari 1 detik
    Excel-nya sendiri masih sibuk membuka file itu

  • DuckDB memang hebat, tetapi pemuatan ekstensi dinamis berbenturan dengan code signing sehingga sulit dipakai di aplikasi komersial
    Selain itu, ekstensi spatial memakai komponen LGPL, jadi ada isu lisensi
    Akan bagus kalau fitur yang dibutuhkan bisa dirangkai per paket seperti Apache Arrow
    Contoh: pengiriman array via HTTP pada skala GB/s memakai Arrow Flight, berbagi file memakai Arrow IPC, dan pembacaan Parquet ditambahkan lewat trait terpisah
    Sistem tipe SQL DuckDB juga berbeda dari Arrow, jadi bisa muncul masalah ketidakcocokan tipe
    Arrow menyediakan pustaka native di sebagian besar bahasa

  • Saya penasaran apakah pada satu tabel tunggal dengan miliaran baris data transaksi (30 kolom),
    halaman yang difilter dengan kondisi WHERE bisa diambil dengan cepat
    Di Postgres, bahkan count(*) sederhana pun butuh waktu lama

    • Pada skala seperti ini, sepertinya di DuckDB juga akan selesai dalam hitungan detik
      Kasus lambat yang saya alami biasanya hanya join kompleks atau pemrosesan glob banyak file
    • Untuk mempercepat count, mungkin cache berkala lebih baik daripada indeks
      Jika kondisi WHERE berupa pasangan kolom-nilai yang sederhana, hasilnya mestinya cukup cepat

  • DuckDB bukan sekadar DB yang cepat, tetapi juga punya pengalaman developer (devx) yang sangat bagus
    Mudah untuk mulai dipakai, sehingga ekosistemnya berkembang cepat
    Integrasi Web/WASM juga mengesankan
    Semoga lebih banyak engine kecil seperti ini bermunculan agar kompetisi dan inovasi terus berlanjut