TL;DR
Perbedaan data warehouse dan database operasional ada di tujuan rancangannya. Database operasional dioptimalkan buat nulis dan mengubah transaksi satu per satu secepat mungkin, strukturnya ternormalisasi, dan biasanya cuma nyimpen kondisi terkini. Data warehouse dioptimalkan buat baca jutaan baris sekaligus, strukturnya sengaja diratakan jadi tabel fakta dan dimensi, serta nyimpen riwayat bertahun-tahun.
Database operasional dirancang buat nulis transaksi satu per satu secepat mungkin. Data warehouse dirancang buat baca jutaan baris sekaligus dan meringkasnya.
Dua-duanya nyimpen data, dua-duanya pakai SQL. Karena itu banyak orang ngira data warehouse cuma database yang lebih besar.
Padahal rancangan keduanya berlawanan. Yang bikin database kasir cepat justru yang bikin dia lambat waktu dipakai analisis.
Di bawah ini perbedaannya per aspek, plus tanda kapan kamu butuh dua-duanya.
Perbedaannya ada di tujuan rancangan. Database operasional mengejar kecepatan menulis dan menjaga konsistensi tiap transaksi. Data warehouse mengejar kecepatan membaca data dalam jumlah besar. Semua perbedaan lain, mulai dari struktur tabel sampai lama penyimpanan, turunan dari dua tujuan itu.
| Aspek | Database operasional | Data warehouse |
|---|---|---|
| Tugas utama | Nyimpen transaksi yang lagi jalan | Jawab pertanyaan analisis |
| Pola akses | Banyak tulis, baca sedikit baris | Sedikit tulis, baca jutaan baris |
| Struktur tabel | Ternormalisasi, banyak tabel kecil | Diratakan, tabel fakta dan dimensi |
| Rentang data | Umumnya 6-24 bulan terakhir | Bertahun-tahun, gak dihapus |
| Riwayat perubahan | Ditimpa nilai terbaru | Disimpan lengkap dengan tanggalnya |
| Pemakai | Aplikasi dan pelanggan | Analis, manajemen, dashboard |
| Ukuran query khas | Milidetik | Detik sampai menit |
| Contoh | PostgreSQL di server aplikasi | BigQuery, Snowflake, Redshift |
Baris paling penting di tabel itu adalah riwayat perubahan. Di sistem kasir, kalau harga produk naik, nilai lamanya ditimpa. Di data warehouse, harga lama tetap tersimpan lengkap dengan periode berlakunya, jadi laporan tahun lalu gak berubah sendiri.
OLTP singkatan dari online transaction processing, pola kerja database operasional yang nulis dan mengubah baris satu per satu. OLAP singkatan dari online analytical processing, pola kerja data warehouse yang baca banyak baris sekaligus buat diringkas jadi angka.
Bedanya kelihatan dari bentuk pertanyaan yang dilayani.
Sistem yang jago di satu sisi hampir selalu lemah di sisi lain. Itu bukan kekurangan rancangan, itu memang pilihan yang harus diambil.
Database operasional dinormalisasi supaya gak ada data yang ditulis dua kali. Nama kota disimpan sekali di tabel kota, lalu ditunjuk pakai id dari tabel cabang. Kalau nama kotanya diperbaiki, cukup ubah di satu tempat.
Bagus buat menulis. Repot buat membaca.
-- Di database operasional: 3 JOIN cuma buat omzet per kota
SELECT
k.nama_kota,
DATE_TRUNC('month', t.waktu_transaksi) AS bulan,
SUM(td.qty * td.harga_satuan) AS omzet
FROM transaksi t
JOIN transaksi_detail td ON td.transaksi_id = t.transaksi_id
JOIN cabang c ON c.cabang_id = t.cabang_id
JOIN kota k ON k.kota_id = c.kota_id
WHERE t.waktu_transaksi >= '2025-01-01'
AND t.status = 'selesai'
GROUP BY k.nama_kota, DATE_TRUNC('month', t.waktu_transaksi);Di data warehouse, keterangan digabung ke tabel dimensi yang lebih lebar. Nama kota, provinsi, dan nama cabang ditaruh di satu tabel dim_cabang, walaupun artinya nama kota berulang ratusan kali.
-- Di data warehouse: cukup 2 JOIN, kolomnya udah siap pakai
SELECT
c.kota,
d.nama_bulan,
SUM(f.nilai_rupiah) AS omzet
FROM fakta_penjualan f
JOIN dim_tanggal d ON d.tanggal_key = f.tanggal_key
JOIN dim_cabang c ON c.cabang_key = f.cabang_key
WHERE d.tahun = 2025
GROUP BY c.kota, d.nama_bulan, d.bulan;Pengulangan data di sini disengaja. Ruang penyimpanan sekarang murah, waktu tunggu analis enggak.
Dua query itu sama-sama pakai aggregate function buat ngeringkas. Bedanya cuma di berapa banyak tabel yang harus disambungin.
Karena database operasional nyimpen data per baris. Waktu kamu minta total nilai transaksi setahun, mesin database harus baca seluruh isi tiap baris, termasuk kolom nomor struk dan alamat pelanggan yang gak kamu butuhin.
Data warehouse modern nyimpen data per kolom. Kalau kamu cuma minta kolom nilai, cuma kolom itu yang dibaca. Buat tabel dengan 30 kolom, bedanya bisa terasa banget.
Ada dua efek samping lain yang sering diremehkan:
Ini alasan paling praktis buat misahin dua sistem itu, bahkan sebelum urusan skema dibahas.
Toko Berkah punya 4 cabang dan satu database PostgreSQL yang melayani semua kasir. Tiap Senin pagi jam 8, tim keuangan jalanin query rekap mingguan.
Query itu makan waktu 3 menit 40 detik dan bikin waktu tanggap aplikasi kasir naik dari 90 milidetik jadi 2 detik selama query jalan. Kasir cabang ngeluh tiap Senin.
Setelah data disalin tiap malam ke skema terpisah berbentuk tabel fakta dan dimensi, query yang sama selesai dalam 4 detik dan aplikasi kasir gak kesentuh sama sekali.
Yang bikin cepat bukan mesin baru. Servernya sama persis. Yang berubah cuma dua hal: jumlah JOIN turun dari 4 jadi 2, dan nilai per transaksi udah dihitung di muka waktu proses penyalinan.
Efek sampingnya juga muncul di sisi lain. Karena riwayat harga sekarang disimpan, laporan margin tahun 2023 berhenti berubah tiap kali ada penyesuaian harga baru. Sebelumnya angka itu bergeser diam-diam dan bikin tim keuangan bingung tiap audit.
Semua bisnis butuh database operasional. Data warehouse itu tambahan yang dipasang waktu kebutuhan analisis mulai bentrok sama kebutuhan transaksi.
Lima tanda yang biasanya muncul duluan:
Kena tiga dari lima, mulai rencanain. Kena satu, benerin dulu query dan index yang ada.
Jalan tengah yang murah: bikin salinan baca dari database utama, lalu arahkan semua query analisis ke sana. Ini gak nyelesein soal riwayat dan struktur, tapi langsung ngilangin gangguan ke aplikasi.
Lewat proses ETL yang jalan terjadwal. Tiga tahapnya: tarik data dari sumber, ubah formatnya biar seragam, lalu masukin ke tabel tujuan.
Yang perlu kamu putuskan di awal cuma dua hal.
Pertama, seberapa sering. Buat laporan penjualan harian, sekali sehari jam 2 pagi udah cukup. Tiap jam cuma masuk akal kalau ada orang yang beneran ambil keputusan tiap jam.
Kedua, salin semua atau sebagian. Nyalin seluruh tabel tiap malam gampang ditulis tapi berat kalau datanya udah puluhan juta baris. Nyalin cuma baris yang berubah lebih hemat, tapi kamu butuh kolom penanda waktu perubahan yang bisa dipercaya.
Buat mulai, skrip Python terjadwal udah cukup. Cara nyusunnya ada di panduan dari notebook ke skrip terjadwal.
Kalau tabel di data warehouse kamu bentuknya sama persis sama sumbernya, kamu cuma dapat salinan, bukan data warehouse. Query-nya tetap butuh 8 JOIN dan tetap lambat.
Ini yang paling sering kelewat. Kalau nama produk lama ditimpa, laporan tahun lalu ikut berubah dan orang berhenti percaya sama angkanya.
Satu dashboard yang di-refresh 50 orang tiap pagi sama beratnya dengan 50 query berat serentak ke sistem produksi.
Kalau data sumbernya kotor, hasilnya tetap kotor, cuma jadi lebih cepat salahnya. Pembersihan dilakukan di tahap transformasi, bukan otomatis terjadi.
Proses penarikan data juga bikin beban di sumbernya. Jalanin di luar jam operasional.
Bisa, dan itu wajar buat bisnis kecil. Batasnya kelihatan waktu query laporan mulai bikin aplikasi kasir lemot, atau waktu kamu butuh data dua tahun lalu yang udah dihapus demi jaga performa. Kalau dua tanda itu muncul, saatnya pisahin ke salinan terpisah buat analisis.
OLTP itu pemrosesan transaksi, pola kerja database operasional yang nulis dan mengubah baris satu per satu dengan cepat. OLAP itu pemrosesan analitis, pola kerja data warehouse yang baca jutaan baris sekaligus buat diringkas. Dua-duanya pakai SQL, tapi rancangan tabel dan penyimpanannya dioptimalkan buat hal yang berlawanan.
Karena normalisasi bikin data tersebar ke banyak tabel, dan tiap query analisis harus nyambungin lima sampai sepuluh tabel. Di data warehouse, keterangan digabung ke tabel dimensi yang lebih lebar supaya query cuma butuh satu atau dua JOIN. Konsekuensinya ada pengulangan data, dan itu memang disengaja demi kecepatan baca.
Gak harus. PostgreSQL atau MySQL biasa udah cukup buat data warehouse pertama dengan puluhan juta baris, asal skemanya disusun bener. Software khusus seperti BigQuery, Snowflake, atau ClickHouse baru kerasa bedanya di skala ratusan juta baris ke atas, karena mereka nyimpen data per kolom, bukan per baris.
Ikutin ritme keputusan yang dilayani. Buat laporan penjualan harian, sekali sehari di luar jam sibuk udah cukup dan paling hemat. Pembaruan tiap jam masuk akal kalau ada tim yang beneran ambil tindakan tiap jam, misalnya operasional gudang. Pembaruan langsung jarang sepadan biayanya buat pelaporan biasa.
Ringkasnya: database operasional cepat buat nulis satu baris, data warehouse cepat buat baca sejuta baris. Struktur tabelnya berlawanan karena tujuannya berlawanan.
Kalau laporanmu sekarang masih jalan lancar di satu database, biarin dulu. Pisahin waktu gangguannya udah kerasa, bukan karena istilahnya keren.
Buat memahami komponen dan skema bintangnya lebih detail, lanjut ke data warehouse adalah: konsep, komponen, dan kapan dibutuhkan.
Mau latihan nulis query agregat di skema bintang pakai dataset retail Indonesia? Coba modul JOIN dan GROUP BY di NgulikSQL.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.