ETL vs ELT: Bedanya dan Kenapa Sekarang Banyak yang Pindah

ETL dan ELT beda di satu hal: kapan data-nya dibentuk ulang. ETL bentuk dulu di luar, baru masukin ke data warehouse. ELT masukin data mentah dulu, bentuknya nyusul di dalam warehouse pakai SQL.

Kedengerannya sepele. Tapi urutan ini nentuin berapa server yang kamu bayar, seberapa cepat data sampai ke dashboard, dan seberapa gampang kamu benerin logika yang salah.

Aku bakal jelasin dua-duanya pakai contoh toko_berkah — dataset penjualan UMKM yang biasa dipakai buat latihan di ngulikdata — plus kapan sebaiknya kamu pilih yang mana.

Apa itu ETL?

ETL adalah pola pemindahan data dengan tiga langkah: Extract (tarik data dari sumber), Transform (bersihin dan ubah bentuknya di server terpisah), lalu Load (masukin hasil bersihnya ke data warehouse). Warehouse cuma nerima data yang udah rapi dan siap dipakai.

Pola ini lahir waktu penyimpanan mahal dan warehouse lemot. Ngolah data mentah di dalam warehouse dulu itu boros banget, jadi orang ngolahnya di luar.

Alurnya kayak gini di toko_berkah:

1. Tarik file penjualan harian dari kasir, plus tabel produk dari Google Sheets.
2. Di server transform: gabungin dua sumber, buang transaksi batal, konversi tanggal ke format standar, hitung kolom total_harga.
3. Masukin tabel bersih itu ke warehouse. Selesai.

Yang masuk warehouse cuma hasil akhirnya. Data mentah? Nggak ikut.

Apa itu ELT?

ELT adalah pola yang sama tapi urutannya ditukar: Extract, Load, lalu Transform. Data mentah dimasukkan apa adanya ke warehouse, dan semua pembersihan dijalankan di dalam warehouse pakai query SQL.

Jadi warehouse-nya nyimpen dua lapis. Lapis mentah (raw), dan lapis hasil transform yang dipakai dashboard.

Contoh transform-nya di ELT ditulis sebagai SQL biasa:

-- Lapis mentah: raw.penjualan (apa adanya dari kasir)
-- Lapis siap pakai: mart.penjualan_bersih

CREATE OR REPLACE TABLE mart.penjualan_bersih AS
SELECT
    p.id_transaksi,
    CAST(p.tanggal AS DATE)          AS tanggal,
    p.id_produk,
    k.nama_produk,
    k.kategori,
    p.jumlah,
    p.harga_satuan,
    p.jumlah * p.harga_satuan         AS total_harga
FROM raw.penjualan     AS p
JOIN raw.produk        AS k
  ON p.id_produk = k.id_produk
WHERE p.status <> 'batal'
  AND p.jumlah > 0;

Nggak ada tool khusus. Cuma SQL yang jalan di dalam warehouse. Kalau kamu belum kuat di JOIN dan CAST, dua fungsi itu yang paling sering muncul di query transform.

Kenapa banyak tim yang pindah ke ELT?

Alasan utamanya: warehouse cloud sekarang jauh lebih cepat dan lebih murah dari 10 tahun lalu.

BigQuery bisa nge-scan puluhan giga dalam hitungan detik, dan kamu cuma bayar sesuai data yang diproses. Ngolah data mentah di dalam warehouse udah gak nyeremin lagi.

Tiga hal yang bikin ELT menang di praktik:

1. Data mentah kesimpen. Salah nulis logika transform? Tinggal perbaiki query, jalanin ulang. Nggak perlu narik ulang data dari sumber. Di ETL, kalau data mentahnya udah kebuang, kamu harus extract lagi dari awal.

2. Satu bahasa buat semua orang. Transform di ELT ditulis pakai SQL. Analis yang udah bisa SQL langsung bisa baca dan benerin logikanya sendiri, gak perlu nunggu data engineer.

3. Satu server lebih sedikit. Server transform di ETL itu mesin yang harus kamu urus, patch, dan bayar terus, walaupun cuma jalan 20 menit sehari.

Tapi ELT bukan jawaban buat semua kasus. Aku bahas batasnya di bawah.

Perbandingan ETL vs ELT: tabelnya

Aspek	ETL	ELT
Tempat transform	Server terpisah	Di dalam warehouse
Bahasa transform	Python, Java, tool ETL	SQL
Data mentah disimpan?	Nggak (biasanya)	Iya
Biaya penyimpanan	Lebih rendah	Lebih tinggi (nyimpen mentah + hasil)
Biaya compute	Server transform tetap nyala	Bayar per query warehouse
Benerin logika salah	Extract ulang dari sumber	Jalanin ulang query
Data sensitif	Bisa disaring sebelum masuk	Masuk dulu, harus di-mask duluan
Cocok buat	Aturan privasi ketat, sumber on-premise	Warehouse cloud, tim yang kuat SQL

Contoh kasus: toko_berkah pindah dari ETL ke ELT

toko_berkah punya 3 cabang, 84.000 baris transaksi setahun. Datanya nyebar di tiga tempat: aplikasi kasir, Google Sheets buat stok, dan file CSV ekspor dari marketplace.

Versi ETL-nya: satu script Python jalan tiap malam jam 23.00 di server kecil. Script itu narik ketiga sumber, gabungin, bersihin, terus masukin satu tabel final ke warehouse.

Masalahnya muncul pas ada permintaan baru dari owner: "Bisa lihat penjualan per jam gak?"

Ternyata kolom jam udah kebuang di tahap transform. Data yang tersimpan cuma agregat harian. Buat jawab pertanyaan itu, tim harus narik ulang 12 bulan data dari kasir — dan API kasirnya cuma nyimpen 90 hari terakhir. Data 9 bulan sebelumnya hilang.

Setelah pindah ke ELT, semua kolom mentah masuk ke raw.penjualan, termasuk timestamp lengkapnya. Pertanyaan baru dari owner tinggal dijawab pakai query, bukan pakai proyek migrasi.

-- Pertanyaan owner: jam berapa paling ramai?
SELECT
    EXTRACT(HOUR FROM waktu_transaksi) AS jam,
    COUNT(*)                           AS jumlah_transaksi,
    SUM(total_harga)                   AS omzet
FROM mart.penjualan_bersih
WHERE tanggal >= DATE '2026-01-01'
GROUP BY jam
ORDER BY omzet DESC;

Hasilnya bikin owner kaget. Jam 19.00–21.00 nyumbang 34 persen omzet harian, padahal jadwal shift karyawan penuh justru ditaruh di jam 10.00–14.00. Jadwal shift-nya digeser bulan berikutnya.

Angka lain dari migrasi ini: biaya bulanan turun dari Rp 1.250.000 (server transform + warehouse) jadi Rp 740.000 (warehouse doang). Waktu pipeline dari 41 menit jadi 12 menit, karena warehouse ngolah paralel sementara script Python-nya jalan satu-satu.

Kapan ETL masih lebih masuk akal?

Tiga situasi ini bikin ETL tetap pilihan yang benar:

Data sensitif yang gak boleh nyentuh warehouse. Kalau aturan internal atau regulasi ngelarang NIK atau data kesehatan disimpan mentah di cloud, transform (termasuk masking) harus jalan sebelum load.

Sumber datanya raksasa tapi yang dipakai dikit. Log server 500 GB per hari, tapi kamu cuma butuh ringkasan 200 MB? Ngolah di luar lebih hemat daripada nyimpen 500 GB mentah tiap hari.

Warehouse-nya on-premise dan lemot. Kalau database kamu server fisik di kantor yang udah ngos-ngosan, jangan tambahin beban transform ke situ.

Kesalahan umum waktu pindah ke ELT

Numpuk semua data mentah tanpa dokumentasi. Setahun kemudian gak ada yang tau tabel raw_v2_final_fix itu apa. Kasih nama yang jelas dan tulis satu paragraf keterangan per tabel.

Jalanin transform tiap 15 menit padahal data sumber update harian. Ini penyebab nomor satu tagihan warehouse membengkak. Samain jadwal transform sama jadwal update sumbernya.

Nulis satu query transform sepanjang 400 baris. Pecah jadi beberapa tabel bertahap: raw, staging, mart. Tiap tahap gampang dicek sendiri kalau ada angka yang aneh.

Lupa mask data sensitif. Kalau data pelanggan ikut masuk mentah, hash nomor HP-nya di tahap load. Ini satu baris kerjaan yang bisa nyelametin kamu dari masalah besar.

Anggap ELT bikin data otomatis bersih. Nggak. ELT cuma mindahin tempat bersih-bersihnya. Kalau kolom tanggal di sumber isinya campur "12/06/2026" sama "2026-06-12", kamu tetep harus benerin.

Gimana cara mulai kalau tim kamu masih kecil?

Nggak perlu langsung beli Fivetran atau Snowflake. Setup paling murah yang udah bener-bener ELT:

1. Extract + Load: script Python 50 baris yang narik CSV dan masukin ke Postgres. Jalanin pakai cron tiap malam.
2. Transform: file SQL yang dijalanin berurutan. Simpan di Git biar keliatan siapa ngubah apa.
3. Naik kelas kalau perlu: pas file SQL-nya udah lewat 10, baru pindah ke dbt yang ngurus urutan dan dependensi antar model otomatis.

Postgres gratis. Cron gratis. Yang kamu butuhin cuma SQL yang cukup buat nulis GROUP BY dan JOIN dengan pede.

FAQ

ETL dan ELT bedanya cuma di urutan huruf?

Urutan hurufnya beda karena urutan kerjanya beda. Di ETL, data dibersihin dulu di server perantara, baru dimasukkan ke warehouse. Di ELT, data mentah masuk warehouse duluan, transform-nya nyusul pakai SQL di dalam warehouse. Konsekuensinya beda: ETL cuma nyimpen data yang udah rapi, ELT nyimpen versi mentahnya juga jadi kamu bisa ngulang transform kapan aja.

ELT lebih murah dari ETL?

Tergantung. ELT hemat karena kamu gak perlu bayar server transform terpisah. Tapi biaya compute warehouse bisa naik kalau query transform-nya boros. Di toko_berkah, pindah ke ELT nurunin total biaya sekitar 40 persen, sebagian besar dari server transform yang dimatiin. Yang bikin balik mahal biasanya query yang jalan tiap jam padahal datanya cuma update harian.

Kalau data-nya sensitif, ELT aman gak?

Data mentah masuk warehouse dulu, jadi data sensitif kayak NIK atau nomor HP ikut kesimpan. Kalau aturan internal kamu ngelarang itu, mask atau hash dulu sebelum load. Pola yang umum: masking di tahap extract, sisanya transform di warehouse. Jadi masih ELT, cuma ada satu langkah pengaman di depan.

Aku kerja pakai Excel doang, perlu tau ETL atau ELT?

Perlu tau konsepnya, gak perlu pakai tool-nya sekarang. Pas kamu copy data dari beberapa file, bersihin, terus tempel ke satu sheet gabungan, itu ETL manual. Ngerti polanya bikin kamu lebih gampang paham pas nanti tim data ngomongin pipeline. Dan kalau data kamu udah lewat 1 juta baris, ini sinyal buat mulai pindah ke database.

Tool apa yang dipakai buat ELT?

Buat extract dan load biasanya pakai Fivetran, Airbyte, atau script Python sendiri. Buat transform-nya, dbt paling sering dipakai karena semua logikanya ditulis pakai SQL biasa dan bisa di-version control pakai Git. Warehouse-nya BigQuery, Snowflake, atau Redshift. Kalau data kamu masih di bawah 50 GB, Postgres biasa pun udah cukup.

Penutup

Tiga hal yang perlu kamu bawa pulang:

• ETL transform di luar warehouse, ELT transform di dalam warehouse pakai SQL.
• ELT menang di fleksibilitas — data mentah kesimpen, jadi pertanyaan baru dari bos gak butuh proyek migrasi.
• ETL masih relevan buat data sensitif dan sumber raksasa yang cuma sedikit dipakai.

Yang bikin kamu berguna di dua-duanya sama: SQL. Semua logika transform di ELT itu SELECT, JOIN, dan GROUP BY. Kalau mau latihan sampai lancar, coba NgulikSQL — bisa langsung praktek di browser tanpa install apa-apa.

Lanjut baca: Data Warehouse vs Data Lake buat tau di mana data mentah kamu sebaiknya diparkir.