Saya menemukan bahwa memuat 112.647 baris pada tabel fakta dalam proyek Data Warehouse e‑commerce menggunakan PostgreSQL memakan waktu lebih dari 25 menit, sehingga query harus dibatalkan. Semua aspek teknis — data yang sudah dibersihkan, skrip SQL yang benar, dan dimensi yang terdefinisi — tampak layak, namun proses INSERT tetap berjalan lambat tanpa menghasilkan pesan kesalahan yang jelas.
Dataset yang used merupakan Brazilian E‑Commerce Public Dataset by Olist, mencakup 9 file CSV yang saling terkait: 99.441 pesanan, 112.650 baris penjualan, 103.886 pembayaran, 104.719 ulasan, 32.951 produk, 3.095 penjual, 1.000.163 catatan geolokasi, serta beberapa kesalahan data yang sering diabaikan. Antara lain, satu pesanan dapat memiliki beberapa pembayaran dan ulasan, yang jika digabung langsung ke tabel fakta akan menyebabkan penggandaan penjualan dan total penjualan yang tidak akurat.
Untuk mengatasi hal ini, saya merancang arsitektur berjenjang: CSV → staging → model dimensi → view → analisis, dijalankan dalam empat skrip yang dapat dijalankan berurutan dan idempotent. Model yang dihasilkan berupa schema bintang (star schema) dengan satu tabel fakta fact_sales pada level line‑item pesanan, serta lima dimensi (customer, product, seller, payment, date) yang dilengkapi dengan surrogate key, primary‑foreign key, constraint CHECK, dan UNIQUE. Langkah ETL utama melibatkan deduplikasi hubungan 1:N sebelum penggabungan ke fakta, menggunakan ROW_NUMBER() untuk memilih pembayaran utama (importer tertinggi) dan ulasan terbaru per pesanan.
Proses dimulai dengan memuat dimensi yang berhasil tanpa kendala, namun tabel fakta justru terhambat. Saya memeriksa blokir, data tak valid, dan kondisi transaksi, namun tidak ada indikasi yang mengarah pada kesalahan tersebut. Akibatnya, saya menyadari bahwa seluruh alur ETL dijalankan dalam satu transaksi, sehingga pada saat memasukkan baris ke fakta, dimensi masih berada dalam transaksi yang belum di‑commit. PostgreSQL, yang tidak memperbarui statistik dalam transaksi, menganggap dimensi kosong dan memilih strategi eksekusi yang sangat mahal.
Penilaian statistik yang salah menyebabkan planner memilih Nested Loop dengan Sequential Scan, yang berarti untuk setiap satu dari 112.650 baris fakta, seluruh dimensi dipindai ulang. Ini menghasilkan bilangan komputasi sebesar miliaran comparasi, menjelaskan mengapa waktu eksekusi menjadi sangat lama. Solusi yang ditemukan melibatkan eksekusi perintah ANALYZE pada setiap tabel dimensi tepat sebelum memuat fakta, sehingga statistik diperbarui meski masih dalam transaksi, dan planner beralih ke strategi Hash Join yang jauh lebih efisien.
Setelah menambahkan lima perintah ANALYZE — untuk dim_customer, dim_product, dim_seller, dim_payment, dan dim_date — waktu INSERT turun drastis menjadi hitungan detik. Pengalaman ini menegaskan bahwa optimizer PostgreSQL bergantung pada statistik yang akurat; bila statistik dimanfaatkan secara tidak tepat, planner akan menghasilkan rencana eksekusi yang tidak realistis tanpa memberi peringatan apa pun, hanya dengan menunggu tanpa henti. Upaya memperbaiki statistik menjadi kunci utama untuk mempercepat proses ETL dalam skala produksi.
Setelah data warehouse berhasil ter‑load, saya menulis 12 pertanyaan bisnis menggunakan CTE, fungsi window, dan fungsi khusus. Hasilnya mengejutkan: (1) logistik tidak memengaruhi kepuasan, malah memperburuknya — rata‑rata nilai ulasan turun signifikan seiring peningkatan delay, (2) tingkat retensi pelanggan sangat rendah, hanya 3,05 % pelanggan yang kembali membeli namun menanggung 5,71 % pendapatan, menunjukkan celah besar dalam strategi retensi, dan (3) “power sellers” men dominate — kuartil atas penjual menghasilkan 86,58 % total pendapatan, lebih konsentrat daripada prinsip 80/20 yang klasik.
Dari serangkaian pengalaman ini, pelajaran utama bukan hanya pada teknik SQL lanjutan, tetapi pada keputusan tak terlihat yang dapat merusak integritas analisis: join yang tidak disamakan menyebabkan penggandan penjualan, pencalian id customer yang salah mengubah KPI, dan kesalahan penulisan header CSV yang tak terdeteksi. Selanjutnya, proyek akan melanjutkan dengan pendekatan incremental load dan dimensi customer berjenis SCD tipe 2 untuk melacak evolusi pola pembelian. Kode lengkap tersedia di GitHub, sebagai dokumentasi praktis bagi yang ingin menerapkan data warehouse berbasis PostgreSQL pada dataset e‑commerce nyata.