DuckLake: Format Lakehouse Terbuka yang Pakai SQL dan Parquet

DuckLake adalah format lakehouse terbuka yang menyimpan seluruh metadata di database SQL biasa dan datanya di file Parquet. Format ini dikembangkan tim DuckDB dan diumumkan lewat blog DuckLake: SQL as a Lakehouse Format pada 27 Mei 2025 oleh Mark Raasveldt dan Hannes Mühleisen. Repositori resminya sudah mengumpulkan lebih dari 3.000 bintang di GitHub, dengan lisensi MIT dan rilis terakhir menyentuh 8 Oktober 2026. Inti idenya sederhana: jangan simpan katalog di tumpukan file JSON seperti format lakehouse lama, pakai database SQL yang sudah terbukti menangani transaksi dan konkurensi.

TL;DR

• DuckLake memisahkan dua hal: metadata di database SQL, data di file Parquet.
• Pilihan katalog database menentukan skala: DuckDB untuk satu klien, SQLite untuk beberapa klien lokal, PostgreSQL untuk lakehouse multi-pengguna.
• DuckDB bisa membaca dan menulis DuckLake langsung lewat ekstensi ducklake.
• Time travel tersedia lewat klausa AT (VERSION => n) tanpa menyalin ulang seluruh tabel.
• Format ini bersaing langsung dengan Iceberg dan Delta Lake, tapi tanpa lapisan katalog berbasis file.

Apa yang membuat DuckLake berbeda dari lakehouse berbasis file?

Perbedaan utamanya ada di tempat metadata disimpan. Iceberg dan Delta Lake menyimpan daftar file serta versi tabel dalam file metadata terpisah, sementara DuckLake menaruh semuanya di database SQL seperti DuckDB, SQLite, PostgreSQL, atau MySQL. Konsekuensinya, operasi seperti menambah snapshot, menandai file terhapus, atau membaca versi lama menjadi transaksi database biasa, bukan urusan menulis dan membaca banyak file kecil.

Dokumentasi DuckLake menyebut pola penyimpanan ini sebagai katalog terintegrasi. Karena metadata ikut aturan ACID database, pembaca dan penulis tidak perlu lagi berkoordinasi lewat protokol kustom atau layanan katalog terpisah. Data tetap dalam format terbuka Parquet, jadi file-nya masih bisa dibaca tool lain di luar ekosistem DuckDB.

Berapa jumlah klien yang bisa memakai satu DuckLake?

Jawabannya bergantung pada jenis katalog database yang dipilih, dan ini batas paling penting untuk dipahami sebelum mulai. Menurut halaman resmi Choosing a Catalog Database, ada tiga tingkat: DuckDB sebagai katalog membatasi kamu pada satu klien saja, SQLite cocok untuk beberapa klien lokal di satu mesin, dan PostgreSQL adalah pilihan untuk lakehouse multi-pengguna dengan klien yang mungkin tersebar di jaringan.

Praktisnya, kalau kamu cuma menjalankan analitik lokal di laptop atau satu server, katalog DuckDB sudah cukup. Begitu ada dua proses yang perlu menulis ke lakehouse yang sama secara bersamaan, naikkan katalog ke SQLite. Untuk tim yang mengakses dari beberapa mesin, PostgreSQL bukan sekadar saran, tapi syarat supaya koordinasi transaksi tetap benar.

Bagaimana cara mulai memakai DuckLake di DuckDB?

Caranya hanya butuh dua perintah: pasang ekstensi lalu attach ke lakehouse. Setelah ekstensi terpasang, kamu bisa membuat tabel, menulis data, dan membacanya kembali dengan SQL standar, persis seperti tabel DuckDB biasa. DuckDB akan menaruh metadata di file katalog dan menyebar data ke file Parquet di direktori yang kamu tentukan lewat opsi DATA_PATH.

Yang menarik, tabel di DuckLake mendukung operasi update dan delete, sesuatu yang tidak bisa dilakukan tabel Parquet lewat query langsung. Saat kamu mengubah satu baris, DuckDB tidak menulis ulang seluruh file, melainkan mencatat perubahan di katalog dan menandai file lama sebagai tidak terpakai. Model ini disebut copy-on-write dengan penghapusan logis, dan itu sebabnya versi lama tabel tetap bisa dibaca.

Aspek	Katalog DuckDB	Katalog SQLite	Katalog PostgreSQL
Jumlah klien	Satu klien	Beberapa klien lokal	Multi-pengguna, klien remote
Cocok untuk	Data warehousing lokal	Beberapa proses di satu mesin	Lakehouse bersama tim
Butuh server	Tidak	Tidak	Ya
Kunci konkurensi	Paling sederhana	Menengah	Paling matang

Kapan harus pindah dari Iceberg atau Delta Lake ke DuckLake?

Pindah masuk akal kalau masalah utamamu adalah kerumitan katalog, bukan volumenya data. Kalau tim kamu sudah punya ekosistem Spark dan layanan katalog seperti REST catalog yang berjalan mulus, menggantinya belum tentu memberi keuntungan. Tapi kalau kamu lelah mengurus file metadata kecil yang menumpuk, konflik commit, dan alat katalog terpisah yang harus dijaga hidup, pendekatan SQL sebagai katalog menawarkan jalan yang jauh lebih sederhana.

Ada satu catatan penting: DuckLake bukan format yang menyelesaikan semua skenario. Untuk query ad hoc dari satu mesin, DuckDB langsung ke Parquet sering kali sudah cukup dan DuckLake menambah lapisan yang tidak perlu. Manfaatnya baru terasa ketika kamu butuh transaksi, versi tabel, dan lebih dari satu penulis.

Dua keputusan apa yang harus diambil sebelum mulai?

Dokumentasi DuckLake menyebut ada dua keputusan yang perlu kamu ambil di awal: database katalog mana yang dipakai untuk menyimpan metadata, dan di mana file data disimpan. Dalam kasus paling sederhana, keduanya lokal, memakai satu berkas DuckDB sebagai katalog dan satu folder di komputermu sebagai penyimpanan file. Kombinasi ini paling cepat dimulai dan tidak membutuhkan server apa pun.

Yang perlu diingat, keputusan katalog ini tidak mudah diubah di tengah jalan tanpa migrasi. Jadi pikirkan sejak awal apakah lakehouse ini akan dipakai satu orang, satu mesin dengan beberapa proses, atau satu tim yang mengakses dari jaringan. Kesalahan paling umum adalah memulai dengan katalog DuckDB untuk proyek yang ternyata butuh beberapa penulis, lalu baru sadar batas satu kliennya mengganggu.

Database DuckLake sendiri dibuat dengan cara yang tidak biasa: kamu tidak menjalankan perintah pembuatan khusus, melainkan langsung melakukan attach. Begitu di-attach, database itu siap dipakai dan tabel bisa langsung dibuat, diisi, lalu dibaca kembali seperti database DuckDB biasa.

Fitur lakehouse apa saja yang ikut tersedia?

Menurut halaman dokumentasi resminya, DuckLake menyediakan seluruh fitur yang biasanya diharapkan dari format lakehouse. Kamu bisa menjalankan query time travel untuk melihat kondisi tabel di versi sebelumnya, memanfaatkan partisi data supaya pembacaan lebih efisien, dan melakukan evolusi skema tanpa membangun ulang seluruh tabel. Yang membuat pendekatan ini berbeda adalah semua kemampuan itu berdiri di atas database SQL, bukan di atas tumpukan berkas metadata.

Time travel adalah contoh paling jelas kenapa model ini masuk akal. Karena setiap perubahan dicatat sebagai transaksi di katalog, membaca versi lama tabel hanya berarti menanyakan katalog tentang kondisi pada saat itu, lalu mengambil file Parquet yang relevan. Tidak ada penyalinan seluruh dataset, dan tidak ada direktori snapshot terpisah yang harus dirapikan secara berkala.

Evolusi skema juga lebih sederhana karena definisi kolom hidup di tabel katalog. Menambah kolom baru, mengubah tipe, atau mengganti nama kolom adalah operasi metadata, bukan penulisan ulang semua file data. File Parquet lama tetap terbaca karena katalog yang menjelaskan bagaimana cara memetakan kolom lama ke skema terkini.

Di mana DuckLake masih kalah dari format mapan?

Keunggulan DuckLake datang dari kesederhanaan, dan justru di situ pula batasnya. Ekosistem Iceberg jauh lebih matang untuk skenario lintas mesin dengan banyak mesin pemroses yang berbeda, karena format itu sudah punya implementasi luas di banyak produk. DuckLake masih muda: repositorinya baru dibuat 3 Maret 2025, dan ekosistem tooling di sekitarnya belum seluas itu.

Selain itu, memilih katalog DuckDB atau SQLite sebagai metadata berarti katalognya terikat pada mesin tempat berkas itu berada. Itu tidak masalah untuk analitik lokal, tapi langsung jadi persoalan begitu kamu ingin menjalankan query dari mesin kedua secara bersamaan. Di titik itu kamu harus naik ke katalog PostgreSQL, dan itu menambah komponen yang harus dijaga.

Apa konsekuensi operasional dari memakai SQL sebagai katalog?

Konsekuensi terbesarnya, kamu mewarisi semua yang sudah matang di dunia database: transaksi, isolasi, indeks, dan alat pemantauan yang sudah ada. Ketika ada masalah, kamu memeriksa tabel katalog dengan SQL biasa, bukan menelusuri tumpukan berkas JSON yang saling merujuk. Untuk tim kecil yang tidak punya orang khusus mengurus katalog data, perbedaan ini cukup berarti.

Sisi lain yang perlu dipertimbangkan, katalog menjadi titik yang harus dijaga ketersediaannya. Kalau katalognya berjalan di server PostgreSQL, server itu kini bagian dari jalur kritis lakehouse. Ini pertukaran yang jujur: kamu menukar kerumitan mengelola banyak berkas metadata dengan tanggung jawab menjaga satu database. Bagi sebagian tim itu lebih mudah, bagi yang lain justru menambah komponen baru.

FAQ

Apakah DuckLake bisa dibaca tanpa DuckDB?

Bisa, dengan syarat. Datanya tersimpan sebagai file Parquet terbuka, jadi tool apa pun yang bisa membaca Parquet masih dapat mengakses isi tabel. Tapi kamu kehilangan makna katalognya: versi tabel, file mana yang aktif, dan riwayat snapshot hanya hidup di database katalog. Untuk membaca versi terbaru dengan benar, gunakan implementasi yang memahami format katalog DuckLake.

Apakah DuckLake pengganti Iceberg?

Bukan pengganti langsung, lebih tepatnya alternatif dengan trade-off berbeda. Iceberg menang di ekosistem lintas mesin dan dukungan vendor yang luas. DuckLake menang di kesederhanaan operasional karena metadata ditangani database SQL yang sudah kamu kenal. Pilih berdasarkan tim dan beban kerja, bukan berdasarkan siapa yang lebih populer.

Berapa biaya menjalankan DuckLake?

Belum ada data publik soal biaya total operasional, karena bergantung penuh pada katalog database yang kamu pilih. Katalog DuckDB dan SQLite tidak menambah biaya server sama sekali karena berjalan lokal. Kalau memakai PostgreSQL sebagai katalog, biaya muncul dari server database itu sendiri, yang bisa berjalan di mesin yang sama atau layanan terkelola.

Apakah file Parquet DuckLake bisa dipakai tool lain?

Ya. Data selalu ditulis sebagai Parquet, format kolumnar terbuka yang didukung hampir semua mesin analitik modern. Kamu bisa membacanya dengan pandas, Polars, Spark, atau langsung dengan DuckDB. Yang tidak portabel hanya metadata katalog, dan itulah lapisan yang membuat DuckLake punya semantik transaksi serta time travel.

Sumber

• Situs resmi DuckLake (dokumentasi format, panduan katalog database, dan referensi penggunaan; diakses 9 Oktober 2026).
• DuckDB Blog: DuckLake, SQL as a Lakehouse Format (Mark Raasveldt dan Hannes Mühleisen, 27 Mei 2025).
• Dokumentasi: Choosing a Catalog Database (perbandingan katalog DuckDB, SQLite, dan PostgreSQL).
• Repositori GitHub duckdb/ducklake (lisensi MIT, metadata bintang dan aktivitas commit per 8 Oktober 2026).