ETL (Extract, Transform, Load) dan ELT (Extract, Load, Transform) adalah dua pola memindahkan data ke tujuan analitik; bedanya di URUTAN: ETL mentransformasi data sebelum dimuat ke warehouse, sedangkan ELT memuat data mentah dulu baru ditransformasi di dalam warehouse. Huruf-hurufnya persis sama, Extract, Transform, Load, hanya posisi T dan L yang bertukar, dan pertukaran kecil itu mengubah hampir semua keputusan arsitektur di sekitarnya: di mana transformasi dijalankan, berapa biaya compute-nya, dan seberapa fleksibel kamu mengolah ulang data.

Kalau kamu sedang merancang data pipeline pertama dan bingung memilih di antara keduanya, artikel ini membahasnya berurutan: arti tiap huruf E-T-L, alur ETL vs ELT langkah demi langkah, tabel perbandingan lengkap dari sembilan dimensi, kapan sebaiknya pilih ETL dan kapan ELT, kenapa ELT belakangan jadi tren, peran dbt sebagai jantung ELT, kaitannya dengan CDC dan streaming, sampai contoh konkret pipeline data e-commerce. Di akhir ada bagian kesalahan umum dan FAQ yang menjawab pertanyaan-pertanyaan yang paling sering diketik orang.

ETL dan ELT Adalah… (Definisi Singkat)

ETL dan ELT adalah dua pola integrasi data untuk memindahkan data dari sumber (source) ke tujuan analitik (biasanya data warehouse), dan satu-satunya perbedaan mendasarnya adalah urutan langkah transformasi. ETL mengubah data menjadi bentuk final sebelum menaruhnya di warehouse; ELT menaruh data mentah dulu, lalu mengubahnya di dalam warehouse dengan tenaga komputasi warehouse itu sendiri. Keduanya sama-sama menyelesaikan masalah yang sama, bagaimana menyatukan data dari banyak sumber menjadi tabel yang siap dianalisis, tapi menempuh jalan yang berbeda.

Istilah “warehouse” di sini merujuk pada data warehouse: basis data yang dioptimalkan untuk kueri analitik berskala besar, bukan untuk transaksi cepat seperti database aplikasi biasa. Kalau konsep warehouse masih kabur, ada baiknya kamu baca dulu dasar-dasar data warehouse, karena hampir semua diskusi ETL vs ELT berputar di sekitar kapasitas dan biaya warehouse. Dan kalau kamu benar-benar baru di bidang ini, pengantar apa itu data engineering memberi peta besar tempat ETL/ELT berada dalam pekerjaan sehari-hari seorang data engineer.

Penjelasan Tiap Huruf: Extract, Transform, Load

Extract, Transform, dan Load adalah tiga fase inti yang ada di kedua pola, yang berbeda hanya urutan pelaksanaannya. Memahami arti tiap huruf lebih dulu akan membuat perbedaan urutannya jadi jelas dengan sendirinya. Mari bedah satu per satu.

Extract (E), Mengambil Data dari Sumber

Extract berarti mengambil data mentah dari sumbernya: database aplikasi (MySQL, PostgreSQL), API pihak ketiga (payment gateway, marketplace), file (CSV, JSON, Parquet), atau log event. Fase ini identik di ETL maupun ELT, kamu selalu mulai dengan menarik data keluar dari tempat asalnya. Tantangan utamanya adalah melakukannya tanpa membebani sistem sumber dan tanpa melewatkan baris yang berubah.

# Contoh extract sederhana dari database sumber
import pandas as pd
from sqlalchemy import create_engine

source = create_engine("postgresql://user:pass@db-produksi:5432/toko")
orders = pd.read_sql("SELECT * FROM orders WHERE updated_at >= '2026-07-01'", source)

Transform (T), Membersihkan dan Membentuk Ulang Data

Transform adalah proses mengubah data mentah menjadi bentuk yang siap dianalisis: membersihkan nilai kosong, menyeragamkan format tanggal, menggabungkan (join) beberapa sumber, menghitung agregasi, menerapkan aturan bisnis, dan membuang duplikat. Inilah fase yang posisinya berpindah antara ETL dan ELT. Di ETL, transform terjadi di server pemrosesan terpisah sebelum data masuk warehouse; di ELT, transform terjadi di dalam warehouse setelah data mentah dimuat.

Load (L), Memuat Data ke Tujuan

Load berarti menulis data ke tujuan akhir, umumnya data warehouse. Di ETL, yang dimuat adalah data yang sudah bersih dan siap pakai. Di ELT, yang dimuat lebih dulu adalah data mentah, dan transformasi menyusul kemudian sebagai langkah terpisah di dalam warehouse. Perbedaan “apa yang dimuat” inilah konsekuensi paling nyata dari pertukaran urutan T dan L.

ETL

ExtractTransformLoadWarehouse

ELT

ExtractLoadWarehouseTransformdi dalam warehouse

Perbedaannya cuma posisi T (Transform).

Alur ETL vs ELT Step-by-Step

Alur ETL bergerak Extract → Transform → Load: data dibersihkan di tengah jalan lalu yang masuk warehouse sudah rapi. Alur ELT bergerak Extract → Load → Transform: data mentah masuk warehouse dulu, transformasi jadi langkah terakhir di dalam warehouse. Cara termudah memahaminya adalah membayangkan kedua alur sebagai urutan tahap. Berikut diagram teksnya.

Alur ETL:

[Sumber]  →  [Extract]  →  [Transform di server ETL]  →  [Load]  →  [Warehouse: data bersih]
   DB           tarik         bersihkan, join,             tulis        siap dianalisis
   API          data          agregasi di luar warehouse   hasil

Alur ELT:

[Sumber]  →  [Extract]  →  [Load]  →  [Warehouse: data mentah]  →  [Transform di warehouse]
   DB           tarik        tulis        raw / staging               SQL/dbt mengubah
   API          data         apa adanya   tersimpan utuh              jadi tabel final

Perhatikan letak kotak “Transform”. Di ETL ia berada di luar warehouse, di tengah perjalanan, sehingga warehouse hanya pernah menyimpan data yang sudah jadi. Di ELT ia berada di ujung, di dalam warehouse, sehingga warehouse menyimpan dua lapisan: data mentah (raw) dan hasil transformasi. Lapisan raw inilah yang memberi ELT satu keunggulan besar, kalau logika transformasi berubah, kamu tinggal jalankan ulang transformasi dari data mentah yang sudah tersimpan, tanpa perlu menarik ulang dari sumber.

Tabel Perbandingan ETL vs ELT

Perbedaan ETL dan ELT paling ringkas terlihat dari sembilan dimensi berikut: urutan transform, tempat transform, kebutuhan compute warehouse, kecepatan load, fleksibilitas re-transform, kecocokan jenis data, biaya, tooling, dan penyimpanan data mentah. Tabel ini merangkum keduanya berdampingan supaya kamu bisa membandingkannya sekilas.

Dimensi	ETL	ELT
Urutan transform	Sebelum load (di tengah)	Setelah load (di akhir)
Tempat transform	Server/engine ETL terpisah	Di dalam data warehouse
Kebutuhan compute warehouse	Rendah (warehouse cuma menyimpan)	Tinggi (warehouse yang memproses)
Kecepatan load awal	Lebih lambat (transform dulu)	Lebih cepat (muat mentah dulu)
Fleksibilitas re-transform	Rendah (harus ekstrak ulang)	Tinggi (raw tersimpan, tinggal olah ulang)
Cocok untuk	Data terstruktur, skema stabil	Data besar, semi/unstructured
Biaya	Compute terpusat di server ETL	Compute mengikuti pemakaian warehouse
Tooling khas	Informatica, Talend, SSIS, skrip Python	Warehouse cloud + `dbt`
Simpan data mentah?	Umumnya tidak	Ya, raw disimpan untuk re-process

Tabel ini bukan vonis mana yang menang. Baris “kebutuhan compute warehouse” dan “biaya” saling terkait dan menjelaskan kenapa ELT baru masuk akal secara ekonomi belakangan ini, kita bahas sebentar lagi.

Kapan Sebaiknya Pilih ETL?

Pilih ETL ketika data harus dibersihkan sebelum masuk warehouse karena alasan kepatuhan, ketika compute warehouse mahal atau terbatas, atau ketika transformasinya kompleks dan sulit diekspresikan dengan SQL. Meskipun ELT sedang naik daun, ETL sama sekali belum usang, untuk sejumlah kasus ia justru pilihan yang benar. Berikut situasi konkretnya.

1. Compliance dan data sensitif (PII) harus dibersihkan lebih dulu. Kalau data sumber mengandung informasi pribadi seperti nomor KTP, nomor kartu, atau alamat, dan regulasi mewajibkan data itu dimasking atau dibuang sebelum disimpan di warehouse, maka transformasi harus terjadi di depan. Menaruh raw PII di warehouse (cara ELT) bisa langsung melanggar aturan. Di sini urutan ETL, bersihkan dulu, baru muat, bukan sekadar preferensi teknis, tapi kewajiban hukum.

2. Warehouse lama dengan compute mahal atau tidak elastis. Warehouse on-premise gaya lama sering punya kapasitas komputasi tetap dan mahal. Membebani warehouse itu dengan transformasi berat (cara ELT) akan mengganggu kueri analitik yang berjalan bersamaan. Memindahkan transformasi ke server ETL terpisah menjaga warehouse tetap ringan untuk tugas utamanya: melayani kueri.

3. Transformasi kompleks yang sulit ditulis dengan SQL. Sebagian logika, misalnya parsing teks rumit, pemanggilan model machine learning, enkripsi khusus, atau integrasi dengan library Python tertentu, jauh lebih mudah ditulis dalam kode aplikasi ketimbang SQL. Kalau transformasimu banyak yang seperti ini, engine ETL berbasis kode memberi keleluasaan yang tidak dimiliki SQL-di-warehouse.

Kapan Sebaiknya Pilih ELT?

Pilih ELT ketika kamu memakai warehouse cloud modern dengan compute murah dan elastis (BigQuery, Snowflake, DuckDB), ketika datanya besar dan semi-terstruktur, ketika kamu ingin menyimpan data mentah untuk diolah ulang, atau ketika timmu SQL-first. Ini adalah default masuk akal untuk mayoritas tim data baru hari ini. Berikut alasannya satu per satu.

1. Warehouse cloud modern dengan compute elastis. BigQuery, Snowflake, dan bahkan DuckDB untuk skala lokal menawarkan komputasi yang murah, cepat, dan bisa naik-turun sesuai kebutuhan. Ketika memproses data di dalam warehouse jadi murah, argumen utama ETL (jangan bebani warehouse) melemah, inilah pergeseran yang membuat ELT tiba-tiba masuk akal secara ekonomi.

2. Data besar, semi-terstruktur atau tidak terstruktur. JSON bersarang dari API, log event, dan data yang skemanya sering berubah lebih mudah “dituang” apa adanya ke warehouse dulu, lalu dibentuk belakangan sesuai kebutuhan. Warehouse modern bisa menyimpan dan mengkueri kolom JSON secara native, jadi kamu tidak perlu memaksakan skema kaku di depan.

3. Ingin menyimpan raw untuk re-process. Karena ELT selalu menyimpan lapisan mentah, kamu bebas mengubah logika transformasi kapan saja dan menjalankannya ulang tanpa menyentuh sistem sumber. Ini sangat berharga: kebutuhan analitik berubah terus, dan menyimpan raw berarti kamu tidak pernah kehilangan detail yang mungkin berguna nanti.

4. Tim SQL-first. Kalau anggota tim kuat di SQL, analis, analytics engineer, ELT membiarkan mereka menulis transformasi dengan bahasa yang sudah mereka kuasai, langsung di warehouse. Tidak perlu belajar framework ETL terpisah. Untuk memperkuat fondasi ini, SQL untuk data engineering melatih pola kueri yang persis dipakai di tahap transform ELT.

Kenapa ELT Jadi Tren: Cloud Warehouse Murah + dbt

ELT jadi tren karena dua hal terjadi bersamaan: warehouse cloud membuat compute jadi murah dan elastis, dan dbt membuat transformasi berbasis SQL di dalam warehouse rapi, teruji, dan bisa diversion-control. Dulu ELT tidak praktis karena memproses di warehouse itu mahal dan transformasi SQL cenderung berantakan. Dua penghalang itu kini runtuh.

Sisi ekonominya sederhana: ketika BigQuery atau Snowflake menagih per pemakaian dan bisa memindai miliaran baris dalam hitungan detik, memproses data di dalam warehouse tidak lagi jadi kemewahan. Kamu membayar untuk apa yang kamu pakai, dan bisa memproses data raksasa tanpa membeli server ETL khusus. Model biaya ini yang membalik kalkulasi lama.

Peran dbt: Jantung dari ELT

dbt (data build tool) adalah alat yang menjalankan transformasi di dalam warehouse, dan karena itu ia praktis menjadi jantung dari pola ELT. Alih-alih menulis SQL lepas yang sulit dipelihara, dbt membiarkan kamu menulis model transformasi sebagai berkas SQL yang saling bergantung, lengkap dengan pengujian, dokumentasi, dan lineage antar tabel. dbt tidak melakukan Extract atau Load; ia hanya fokus pada huruf T, dan itu tepat karena “transform di dalam warehouse” memang inti ELT.

-- Contoh model dbt: staging orders (transform di dalam warehouse)
-- models/staging/stg_orders.sql
select
    id                        as order_id,
    customer_id,
    lower(trim(status))       as status,
    cast(total_amount as numeric) as total_amount,
    created_at::date          as order_date
from {{ source('toko', 'orders') }}
where created_at is not null

Model di atas mengambil tabel mentah orders yang sudah dimuat ke warehouse, lalu menyeragamkan nama kolom, membersihkan status, dan memperbaiki tipe data, semuanya dengan SQL, dijalankan oleh warehouse. Inilah wujud nyata “T” pada ELT. Kalau kamu ingin mendalami cara kerjanya dari nol, materi dbt sebagai data build tool membahas struktur proyek, model berlapis, dan pengujian bawaannya.

Kaitan dengan CDC dan Streaming

CDC (Change Data Capture) dan streaming adalah teknik memindahkan data secara berkelanjutan, dan keduanya paling sering berpasangan dengan ELT karena data yang masuk kecil-kecil dan terus-menerus lebih enak ditransformasi belakangan di warehouse. Keduanya menjawab satu keterbatasan pipeline batch tradisional: menunggu jadwal harian atau jam-jaman terasa lambat kalau bisnis butuh data segar.

CDC bekerja dengan menangkap setiap perubahan (insert, update, delete) di database sumber begitu terjadi, lalu meneruskannya ke tujuan. Alih-alih menarik seluruh tabel setiap kali (yang boros), CDC hanya mengirim baris yang benar-benar berubah. Ini membuat fase Extract jauh lebih efisien dan mendekati real-time. Untuk memahami mekanismenya, dari membaca log database sampai menerapkan perubahan di hilir, materi CDC change data capture menjelaskannya bertahap.

Streaming melangkah lebih jauh: data mengalir sebagai aliran event kontinu, bukan kumpulan batch. Perbedaan mendasar antara memproses data per-batch versus per-aliran punya konsekuensi arsitektur yang lumayan besar, dan perbandingan streaming vs batch processing memetakan kapan masing-masing pendekatan tepat dipakai. Untuk pipeline pertamamu, batch sudah lebih dari cukup, streaming baru relevan saat kesegaran data dalam hitungan detik benar-benar dibutuhkan.

Contoh Konkret: Pipeline Data E-commerce Indonesia

Bayangkan sebuah toko online yang ingin membuat dashboard penjualan harian, kita rancang pipeline-nya dengan pola ELT, dari extract sampai transform di warehouse. Contoh ini menyatukan semua konsep di atas menjadi satu alur yang bisa kamu tiru. Skenarionya: data pesanan ada di database PostgreSQL aplikasi, data pembayaran datang dari API payment gateway, dan tim ingin tahu total penjualan bersih per hari per kategori produk.

Langkah 1, Extract. Tarik pesanan yang berubah sejak kemarin dari PostgreSQL, dan tarik status pembayaran dari API. Karena hanya menarik yang berubah, extract-nya ringan (inilah pola inkremental yang mendekati semangat CDC).

import pandas as pd
from sqlalchemy import create_engine

source = create_engine("postgresql://analyst:secret@app-db:5432/toko")

query = """
    SELECT id, customer_id, product_id, category, amount, status, created_at
    FROM orders
    WHERE created_at >= CURRENT_DATE - INTERVAL '1 day'
"""
orders = pd.read_sql(query, source)

Langkah 2, Load (mentah). Muat data apa adanya ke skema raw di BigQuery. Tidak ada pembersihan di sini; tujuannya cuma menyimpan salinan mentah supaya bisa diolah ulang kapan pun.

orders.to_gbq(
    destination_table="raw.orders",
    project_id="toko-analytics",
    if_exists="append",
)

Langkah 3, Transform (di warehouse, dengan SQL). Setelah data mentah ada di warehouse, transformasi jadi urusan SQL. Kita hitung penjualan bersih (hanya pesanan yang pembayarannya paid) per hari per kategori:

-- Transformasi di dalam warehouse (jantung ELT)
CREATE OR REPLACE TABLE mart.daily_sales AS
SELECT
    DATE(created_at)          AS sales_date,
    category,
    COUNT(*)                  AS total_orders,
    SUM(amount)               AS gross_amount
FROM raw.orders
WHERE LOWER(status) = 'paid'
GROUP BY sales_date, category
ORDER BY sales_date DESC, gross_amount DESC;

Perhatikan bahwa seluruh logika bisnis, memfilter pesanan lunas, mengelompokkan per kategori, menjumlahkan nilai, hidup di SQL dan dieksekusi oleh warehouse. Kalau besok tim minta metrik baru (misalnya rata-rata nilai pesanan), kamu cukup menulis model transformasi baru dari tabel raw.orders yang sudah tersimpan, tanpa menyentuh database produksi lagi. Itulah keunggulan menyimpan raw yang berulang kali kita sebut.

Untuk membangun kerangka orkestrasi lengkap dari langkah-langkah ini, penjadwalan, penanganan gagal, dan ketergantungan antar-tugas, membangun data pipeline dengan Python memandu dari skrip sederhana sampai pipeline yang tahan banting. Dan buat kamu yang datang dari dunia web dev dan sudah akrab mengambil data lewat ORM sebuah framework, misalnya lewat Eloquent di panduan belajar Laravel untuk pemula, konsep “menarik baris dari database sumber” di fase Extract akan terasa familiar; bedanya di sini tujuannya analitik, bukan melayani request aplikasi.

Kesalahan Umum dan Miskonsepsi

Tiga kesalahan paling sering: mengira ELT selalu lebih baik daripada ETL, lupa memperhitungkan biaya compute warehouse di ELT, dan memaksakan transformasi berat di tahap ETL yang seharusnya dikerjakan di warehouse. Memahami jebakan-jebakan ini menyelamatkanmu dari keputusan arsitektur yang mahal untuk diperbaiki belakangan.

1. Mengira ELT selalu lebih baik

ELT memang sedang tren, tapi “tren” bukan “selalu benar”. Untuk kasus dengan PII yang wajib dibersihkan sebelum disimpan, atau warehouse lama dengan compute mahal, ETL tetap pilihan yang tepat, bahkan satu-satunya yang patuh regulasi. Keputusan ETL vs ELT selalu bergantung konteks: aturan kepatuhan, tipe warehouse, dan keahlian tim. Jangan memilih pola karena sedang populer; pilih karena cocok dengan batasanmu.

2. Lupa biaya compute warehouse di ELT

Karena ELT memproses di dalam warehouse, setiap transformasi memakan compute, dan di warehouse cloud yang menagih per pemakaian, transformasi yang tidak efisien bisa membengkakkan tagihan diam-diam. Kueri yang memindai seluruh tabel berulang kali, model dbt yang dijalankan penuh padahal cukup inkremental, atau join berlebihan semuanya berubah jadi angka di tagihan bulanan.

3. Transformasi di ETL yang seharusnya di warehouse

Kebalikannya juga sering terjadi: tim memindahkan agregasi dan join berat ke skrip ETL di luar warehouse, padahal warehouse modern akan mengerjakannya jauh lebih cepat dan lebih murah.

4. Menyamakan ETL/ELT dengan satu tool tertentu

ETL dan ELT adalah pola, bukan produk. dbt bukan “ELT”, ia komponen transform dari ELT. Sebuah skrip Python bisa mengimplementasikan ETL maupun ELT tergantung urutan langkahnya. Fokuslah pada urutan Extract-Transform-Load, bukan pada nama tool, tool bisa berganti, polanya tetap.

Cek Pemahaman

Dalam pola ELT, di mana tahap Transform dijalankan?

FAQ Seputar ETL dan ELT

Apa itu ETL?

ETL (Extract, Transform, Load) adalah pola integrasi data di mana data diambil dari sumber (Extract), dibersihkan dan dibentuk ulang di server pemrosesan terpisah (Transform), lalu dimuat dalam kondisi sudah rapi ke data warehouse (Load). Ciri khasnya: warehouse hanya pernah menyimpan data yang sudah jadi, karena transformasi terjadi sebelum load.

Apa itu ELT?

ELT (Extract, Load, Transform) adalah pola integrasi data di mana data mentah diambil dari sumber (Extract), langsung dimuat apa adanya ke warehouse (Load), baru kemudian ditransformasi di dalam warehouse itu sendiri (Transform). Ciri khasnya: warehouse menyimpan lapisan data mentah plus hasil transformasi, sehingga data bisa diolah ulang tanpa menarik lagi dari sumber.

Apa perbedaan ETL dan ELT?

Perbedaannya murni pada urutan: ETL mentransformasi data sebelum dimuat ke warehouse, sedangkan ELT memuat data mentah dulu lalu mentransformasinya di dalam warehouse. Konsekuensinya berbeda-beda, ETL menjaga warehouse tetap ringan tapi kurang fleksibel untuk olah ulang, sementara ELT memanfaatkan compute warehouse dan menyimpan raw sehingga sangat fleksibel, dengan konsekuensi biaya compute yang perlu dijaga.

Mana yang lebih baik, ETL atau ELT?

Tergantung konteks, tidak ada yang mutlak lebih baik. Pilih ETL kalau ada kewajiban compliance untuk membersihkan PII lebih dulu, warehouse-nya lama/mahal compute, atau transformasinya sulit ditulis dengan SQL. Pilih ELT kalau kamu memakai warehouse cloud modern (BigQuery, Snowflake, DuckDB), datanya besar dan semi-terstruktur, ingin menyimpan raw untuk re-process, atau timmu SQL-first. Untuk mayoritas tim baru hari ini, ELT jadi default yang masuk akal.

Apakah dbt itu ETL atau ELT?

dbt adalah alat transform yang bekerja di dalam warehouse, jadi ia komponen dari ELT, khususnya huruf “T” yang terjadi setelah Load. dbt tidak melakukan Extract maupun Load; ia hanya mengubah data yang sudah ada di warehouse menjadi tabel-tabel analitik yang teruji dan terdokumentasi. Karena itu dbt sering disebut jantung dari pola ELT modern.

Kapan sebaiknya pakai ETL?

Pakai ETL ketika data sensitif (PII) harus dibersihkan atau dimasking sebelum masuk warehouse demi kepatuhan, ketika warehouse-mu punya compute mahal atau tidak elastis sehingga tidak ideal dibebani transformasi, atau ketika transformasinya kompleks dan lebih mudah ditulis sebagai kode aplikasi ketimbang SQL. Di luar tiga situasi itu, ELT biasanya lebih praktis.

Langkah Selanjutnya

Sekarang kamu sudah pegang inti perbedaan ETL dan ELT: sama-sama Extract-Transform-Load, hanya urutan T dan L yang bertukar, tapi pertukaran itu menentukan di mana transformasi berjalan, berapa biayanya, dan seberapa fleksibel kamu mengolah ulang data. Kamu juga sudah tahu kapan memilih masing-masing, kenapa ELT jadi tren, dan bagaimana dbt, CDC, serta streaming melengkapi gambarannya.

Langkah paling produktif berikutnya adalah mempraktikkannya. Mulai dari materi ETL vs ELT di Hyper Sheets untuk latihan bertahap dengan dataset nyata, lalu terapkan polanya saat membangun pipeline pertamamu dari nol. Setelah pipeline itu jalan, konsep urutan yang kamu pelajari hari ini akan terasa alami, dan kamu bisa memilih pola yang tepat untuk data pipeline-mu sendiri dengan percaya diri. Selamat ngoding!