DuckDB: Menganalisis CSV 5 Juta Baris di Laptop Terbatas

Excel berhenti di 1.048.576 baris. File transaksi setahun kamu isinya 5,2 juta.

Pilihan yang biasa muncul: pecah filenya jadi enam, atau minta akses database ke tim IT dan nunggu dua minggu.

DuckDB ngasih jalan ketiga. Satu file kecil, nggak ada server, dan kamu bisa nulis SQL langsung ke file CSV-nya. Di laptop RAM 8 GB, agregasi omzet per kota dari 5,2 juta baris selesai 3,4 detik.

Apa itu DuckDB?

DuckDB adalah database analitik yang jalan di dalam proses aplikasi kamu, bukan sebagai layanan terpisah. Nggak ada server yang harus dinyalain, nggak ada port, nggak ada user dan password. Dia bisa baca file CSV dan Parquet secara langsung pakai SQL standar, termasuk file yang lebih besar dari RAM.

Cara nyimpen datanya beda dari database yang biasa kamu pakai. PostgreSQL dan MySQL nyimpen per baris, bagus buat aplikasi yang nulis satu transaksi tiap kali. DuckDB nyimpen per kolom, bagus buat pertanyaan model "total penjualan per kota" yang cuma nyentuh 3 dari 20 kolom.

Itu sebabnya query agregasi di DuckDB bisa jauh lebih cepat. Dia nggak baca kolom yang nggak kamu sebut.

Gimana cara pasang DuckDB?

Ada tiga cara, pilih satu.

Lewat Python:

pip install duckdb

Lewat terminal: unduh satu file binary dari halaman rilis resmi, taruh di folder mana pun, lalu jalanin.

duckdb

Lewat R:

install.packages("duckdb")

Nggak ada langkah konfigurasi setelahnya. Panduan pemasangan buat tiap sistem operasi ada di halaman instalasi resmi DuckDB.

Gimana cara baca CSV besar tanpa impor dulu?

Sebut nama filenya di posisi tabel. Itu doang.

SELECT * FROM 'transaksi_2025.csv' LIMIT 10;

DuckDB otomatis nebak pemisah kolom, ada tidaknya baris judul, dan tipe tiap kolom. Buat lihat hasil tebakannya:

DESCRIBE SELECT * FROM 'transaksi_2025.csv';

Cek hasil DESCRIBE sebelum lanjut. Kolom order_id yang isinya 0012345 gampang ketebak jadi angka, dan nol di depannya hilang. Kolom nomor telepon juga sering kena.

Kalau tebakannya meleset, tentukan sendiri:

CREATE VIEW transaksi AS
SELECT * FROM read_csv(
    'transaksi_2025.csv',
    delim = ',',
    header = true,
    types = {
        'order_id': 'VARCHAR',
        'tanggal': 'DATE',
        'kota': 'VARCHAR',
        'kategori': 'VARCHAR',
        'qty': 'INTEGER',
        'nilai': 'BIGINT'
    }
);

Bikin VIEW bukan TABLE di sini disengaja. View nggak nyalin datanya, jadi nggak makan disk tambahan. Filenya tetap dibaca dari tempat asal tiap kali kamu query.

Gimana biar nggak kehabisan RAM waktu query file besar?

Tiga pengaturan yang dijalanin di awal sesi:

SET memory_limit = '4GB';
SET temp_directory = '/tmp/duckdb_spill';
SET threads = 4;

memory_limit nentuin batas atas pemakaian memori. Isi sekitar setengah RAM laptop kamu, biar sistem operasi dan browser masih punya jatah.

temp_directory nentuin folder tempat DuckDB numpahin data waktu memori penuh. Tanpa ini, query berat bisa berhenti dengan pesan kehabisan memori. Pastiin folder itu ada di disk yang ruangnya masih lega, minimal dua kali ukuran file kamu.

threads nentuin jumlah inti prosesor yang dipakai. Di laptop 4 inti, isi 4. Kalau kamu mau tetap bisa kerja lain sambil query jalan, isi 2.

Daftar lengkap pengaturan yang bisa disetel ada di dokumentasi konfigurasi DuckDB.

Query apa yang paling sering kepakai buat data transaksi?

Sintaksnya SQL biasa. Kalau kamu udah pernah nulis GROUP BY, kamu udah bisa pakai DuckDB.

Agregasi per kota per bulan:

SELECT kota,
       date_trunc('month', tanggal) AS bulan,
       COUNT(*) AS jumlah_transaksi,
       SUM(nilai) AS omzet,
       ROUND(AVG(nilai)) AS rata_rata_nilai
FROM transaksi
WHERE tanggal >= DATE '2025-01-01'
GROUP BY kota, bulan
ORDER BY omzet DESC;

Pemeriksaan kualitas data dalam satu query:

SELECT COUNT(*) AS baris,
       COUNT(DISTINCT order_id) AS order_unik,
       COUNT(*) FILTER (WHERE kota IS NULL) AS kota_kosong,
       COUNT(*) FILTER (WHERE nilai <= 0) AS nilai_janggal
FROM transaksi;

Klausa FILTER di sini bikin kamu bisa ngitung beberapa kondisi berbeda sekaligus dalam satu kali baca file. Jauh lebih cepat dibanding jalanin empat query terpisah.

Kalau fungsi agregat kayak COUNT dan SUM masih terasa asing, polanya sama persis kayak di spreadsheet: SUMIFS jadi SUM dengan WHERE, COUNTIFS jadi COUNT dengan WHERE.

Kapan sebaiknya CSV diubah jadi Parquet?

Kalau file yang sama bakal kamu query lebih dari tiga kali.

COPY (SELECT * FROM transaksi)
TO 'transaksi_2025.parquet' (FORMAT PARQUET, COMPRESSION ZSTD);

Hasil di file uji aku:

Format	Ukuran file	Waktu agregasi per kota
CSV	1,42 GB	3,4 detik
Parquet (ZSTD)	184 MB	0,6 detik

Ukurannya turun 87%, waktunya turun jadi seperlima. Proses konversinya sendiri 11 detik, jadi balik modal di query kedua.

Parquet juga bisa dipecah jadi banyak file dan diquery sekaligus:

SELECT kota, SUM(nilai) AS omzet
FROM 'data/transaksi_2025_*.parquet'
GROUP BY kota;

Tanda bintang di situ nyapu semua file yang cocok. Berguna kalau data kamu datang per bulan dalam file terpisah.

Contoh kasus: 5,2 juta transaksi di laptop RAM 8 GB

File uji aku: transaksi_2025.csv, 5.243.180 baris, 1,42 GB, 9 kolom. Laptop RAM 8 GB, prosesor 4 inti, SSD.

Aku bandingin tiga cara ngerjain pertanyaan yang sama: omzet per kota per bulan.

Cara	Waktu	Puncak pemakaian RAM	Catatan
Excel	gagal	-	Kelebihan batas 1.048.576 baris
pandas read_csv	1 menit 52 detik	6,8 GB	Laptop nyaris nggak kepakai selama proses
DuckDB dari CSV	3,4 detik	1,1 GB	Tanpa impor, langsung dari file
DuckDB dari Parquet	0,6 detik	0,4 GB	Setelah konversi 11 detik

Selisih waktu yang 33 kali lipat itu menarik, tapi bukan itu yang paling ngefek buat kerjaan harian. Yang ngefek angka RAM.

Dengan pandas, laptop kepakai penuh selama hampir dua menit dan aku nggak bisa ngapa-ngapain. Dengan DuckDB, aku bisa buka browser dan lanjut kerja sambil query jalan.

Temuan lain dari pemeriksaan kualitas datanya: dari 5.243.180 baris, ada 3.812 order_id yang muncul dua kali. Cuma 0,07%, tapi total nilainya Rp 1,91 miliar. Kalau baris ganda itu nggak ketahuan, laporan tahunan kamu kelebihan Rp 1,91 miliar dari angka yang bener.

Pemeriksaan itu jalan 0,9 detik pakai satu query COUNT(DISTINCT ...). Di Excel, buat 5 juta baris, kerjaan ini nggak mungkin dilakukan sama sekali.

Kesalahan umum waktu mulai pakai DuckDB

• Nggak ngecek DESCRIBE sebelum query. Kolom order_id yang isinya 0012345 bisa ketebak jadi angka, dan nol di depannya hilang. Cek tipe kolom duluan, tentukan manual kalau perlu.
• Lupa nyetel temp_directory. Query berat berhenti dengan pesan kehabisan memori, padahal cuma butuh tempat numpahin data ke disk.
• Bikin TABLE padahal cukup VIEW. CREATE TABLE ... AS SELECT nyalin seluruh data ke file database. Kalau kamu cuma mau baca, VIEW lebih hemat.
• Ngurutin jutaan baris tanpa LIMIT. ORDER BY di 5 juta baris tanpa batas itu operasi paling berat yang bisa kamu jalanin. Tambahin LIMIT 100 kecuali kamu beneran butuh semuanya.
• Ekspor data mentah ke Excel. Ekspor hasil agregasinya. Ringkasan 400 baris per kota per bulan lebih berguna dibanding 5 juta baris yang bikin filenya nggak kebuka.
• Ngira DuckDB pengganti PostgreSQL. DuckDB dirancang buat analisis, satu penulis dalam satu waktu. Buat aplikasi yang dipakai banyak orang bareng dan nulis terus-menerus, tetap pakai database yang memang buat itu.
• Nggak nyimpan query-nya. Simpan file .sql di folder yang sama sama datanya. Tiga bulan lagi kamu nggak bakal inget filter apa yang kamu pakai.

FAQ

DuckDB perlu install server kayak PostgreSQL?

Nggak perlu. DuckDB jalan di dalam proses aplikasi kamu, mirip SQLite. Kamu cukup pasang lewat pip install duckdb buat Python, atau unduh satu file binary buat dipakai di terminal. Nggak ada layanan yang harus dinyalain, nggak ada port yang harus dibuka, dan nggak ada user atau password yang perlu diatur.

DuckDB bisa baca file yang lebih besar dari RAM?

Bisa, selama kamu nyetel batas memori dan folder sementara. DuckDB bakal numpahin data ke disk waktu memori penuh. Query agregasi dan filter aman dijalankan. Yang berat itu operasi yang butuh nahan seluruh data sekaligus, misalnya urutan penuh di jutaan baris atau JOIN antar dua tabel raksasa tanpa filter.

Lebih cepat mana, DuckDB atau pandas?

Buat agregasi di file besar, DuckDB biasanya lebih cepat dan jauh lebih hemat memori, soalnya dia baca kolom yang dibutuhkan doang dan bisa numpahin ke disk. pandas nyimpen semuanya di RAM, jadi file 1,4 GB gampang bengkak jadi beberapa GB. Buat data di bawah 100 ribu baris, bedanya nggak berasa dan pilih yang kamu lebih nyaman.

Apa itu Parquet dan kenapa lebih baik dari CSV?

Parquet adalah format file yang nyimpen data per kolom dan udah dikompres. Ukurannya biasanya 4 sampai 10 kali lebih kecil dari CSV yang isinya sama. Waktu kamu query 3 kolom dari 20 kolom, DuckDB cuma baca 3 kolom itu. Kalau file yang sama bakal kamu query berkali-kali, ubah sekali ke Parquet dan sisanya jadi jauh lebih cepat.

Hasil query DuckDB bisa dibawa ke Excel?

Bisa. Pakai perintah COPY dengan tujuan file CSV, lalu buka hasilnya di Excel. Yang penting, ekspor hasil agregasinya, bukan data mentahnya. Ringkasan 400 baris per kota per bulan jauh lebih berguna di Excel dibanding 5 juta baris yang bikin filenya nggak kebuka.

Penutup

Tiga hal yang bikin DuckDB kepakai buat file raksasa: query langsung ke file tanpa impor, batas memori yang bisa disetel plus tumpahan ke disk, dan konversi ke Parquet buat file yang sering dipakai.

Kalau kamu mau coba hari ini, mulai dari satu baris: SELECT COUNT(*) FROM 'filekamu.csv'. Sepuluh detik, dan kamu udah tahu berapa baris data yang selama ini nggak kebuka di Excel.

Mau ngasah SQL-nya dulu sebelum ngadepin file jutaan baris? Coba latihan interaktif di NgulikSQL, langsung ketik di browser. Kalau datanya udah masuk database bersama tim, cara ngatur siapa boleh lihat apa ada di panduan hak akses data tim kecil.