ETL vs. ELT: When Each One Is the Right Answer

The architecture review meeting started with a debate about ETL versus ELT and ended, four hours later, with a finance person on the call asking which of the two was cheaper.

Nobody could answer the finance person's question. The technical answer was 'it depends.' The depends-on factors were never written down.

I have watched the same conversation in io-pattern-first reviews where teams argue about block size and stripe alignment until somebody points out the workload is bursty enough that the question is irrelevant. The technical debate was real. The technical debate was not the binding constraint. The binding constraint was a cost-allocation decision, dressed up as an architecture decision because the cost-allocation conversation was harder to have honestly.

ETL versus ELT runs the same shape. The framing as a paradigm shift — old way versus new way, on-prem versus cloud, monolithic versus decomposed — is what gets the topic on the agenda. The substance, when teams actually decide, is almost always about where compute happens, who pays for it, and which team owns the transformation logic. None of those questions get asked directly until the architecture meeting has run for several hours.

Step One — The Wrong Assumption

"ELT is the modern approach. We should move to ELT."

"ETL is the legacy pattern. ELT is what cloud-native data stacks do. We should be moving to ELT."

The first instinct treats the choice as a generational one. ETL is the older pattern, designed for on-prem data warehouses with limited compute, where transformation had to happen on dedicated middleware before loading. ELT is the newer pattern, designed for cloud warehouses with elastic compute, where loading raw data first and transforming it inside the warehouse is feasible and increasingly the default. Therefore ETL is legacy, ELT is modern, and the correct direction is from old to new.

The framing is partly true and structurally misleading. ETL is older; ELT is newer. The choice between them is not actually about age. It is about three operational questions: where does compute happen, who owns the transformation logic, and what are the data residency and defensibility requirements. Programs that decide on the basis of "modernity" without answering those three questions discover that the answer to the questions changes the architecture substantially — and sometimes back to ETL.

Step Two — The Partial Signal

Three of four ETL-vs-ELT debates are about engineering. The fourth is about who pays.

Most of the technical debate is real. ELT pushes transformation into the warehouse, which means the warehouse has to be capable of the transformation work and the warehouse's compute is what runs the load. ETL keeps transformation outside the warehouse, on dedicated infrastructure that can be optimized for transformation patterns and that does not contend with query workloads. Each is a legitimate engineering choice with legitimate trade-offs in latency, observability, and operational complexity.

The fourth dimension is cost allocation. In an ELT architecture, the warehouse line item grows because the warehouse is doing the transformation work. In an ETL architecture, the integration platform line item grows because the integration platform is doing the transformation work. The total cost is often comparable; the question of which team's budget pays for it is rarely comparable. Data engineering teams may prefer ELT because it consolidates their work into one platform. Finance teams may prefer ETL because the integration platform's cost is more predictable than the warehouse's elastic compute. Neither preference is wrong; both are operational, not architectural.

This is the partial signal. The technical debate has clear answers in some dimensions. The cost-allocation question has different answers depending on whose budget is being asked, and the architecture decision is downstream of whichever budget conversation happens first.

Step Three — The Failed Fix

You pick ELT for modernization. The warehouse bill triples and the data team becomes a cost center.

The team picks ELT. The migration runs. Six months in, the warehouse bill has tripled. Some of the increase is from elastic compute scaling with the transformation workload, exactly as planned. Some of the increase is from analyst queries running against intermediate transformation outputs that previously did not exist as queryable tables. Some of the increase is from the data team writing transformation logic in SQL because that is what the warehouse runs, and SQL is not always the most efficient expression of the transformation that needed to happen.

The data team is now a meaningful cost center. The CFO asks whether the modernization paid off. The analytical answer is yes — the architecture is more flexible, the data team is more productive, the latency for new data products is lower. The financial answer is harder to articulate, because the previous architecture's cost was distributed across line items the CFO did not associate with the data team, and the new architecture's cost is consolidated into a line item that has the data team's name on it.

The fix did not fix anything because it solved an architectural problem with an architectural decision and did not solve the cost-allocation problem at all. The team is in a politically worse position than before the migration, with a technically better architecture, and the conversation about whether the migration was the right move has nothing to do with the architecture.

Step Four — The Real Failure

It was never a paradigm choice. It was three operational questions, and the architecture is downstream of the answers.

The actual decision has three operational questions. First: where does the transformation compute happen, given what your warehouse is good at and what your integration platform is good at and what your team can operate. Second: who owns the transformation logic, given that ELT tends to consolidate ownership in the data team and ETL tends to distribute it across data engineering and integration engineering. Third: what are the data residency, defensibility, and audit requirements, because some regulated industries require the source-of-record to be the system that captured the data, not a transformed view downstream.

The clean version of the choice is per-pipeline, not per-organization. The pipelines that feed regulatory reporting often want ETL, because the source-of-record discipline is easier to defend when the transformation is documented and the raw data has not been silently mutated. The pipelines that feed analytics often want ELT, because the analytical use case benefits from raw-data access and the warehouse is the natural compute substrate. The pipelines that feed AI training often want a hybrid, because the training corpus needs raw data preserved and the feature engineering layer needs transformations expressible in code.

Programs that pick one architecture across the whole estate end up forcing the wrong choice on some pipelines. Programs that pick per-pipeline end up with operational complexity that some teams cannot sustain. The honest answer is that the choice is contextual, the cost-allocation conversation is structural, and the modernization decision is downstream of both.

Step Five — The Definition

Now the definition lands.

ETL and ELT are two patterns for moving data into an analytical environment — ETL transforms data on dedicated infrastructure before loading, ELT loads raw data and transforms it inside the analytical warehouse. The technical difference is where compute happens. The operational difference is which team's budget pays for it, who owns the transformation logic, and where the data has to be defensible. The right choice is per-pipeline, not per-organization.

Most definitions describe the two as competing paradigms with one being more modern. The framing is technically accurate and operationally misleading. The choice is not paradigmatic; it is contextual. Programs that pick one and apply it everywhere produce the wrong choice on some pipelines and political problems on others.

The discipline is per-pipeline decisions, with the architecture decision downstream of the cost-allocation and defensibility conversations.

What Solix Enforces

Source-of-record discipline survives both patterns; the archive is the boundary.

What Solix's archival and governance platform enforces in this category is the source-of-record discipline that holds across both ETL and ELT. The data is captured into the governed archive at the boundary it leaves the source system, with its schema, lineage, and policy bound at capture — before any transformation happens in either direction. Downstream pipelines, whether ETL or ELT, read from the archive rather than directly from the source. The transformation pattern becomes a downstream choice; the source-of-record discipline does not.

For SAP ECC, Oracle E-Business Suite, regulatory reporting pipelines, and AI training corpora, the same model applies. The defensibility lives at the archive boundary. The architectural choice between ETL and ELT becomes a question of where compute happens, not a question of where the source-of-record lives. Programs that bind the source-of-record to the transformation pattern lose flexibility; programs that bind it to the archive keep both flexibility and defensibility.

Three things to do this week

• List your pipelines and classify each by destination type. Regulatory reporting, operational analytics, AI training, customer-facing data products. The classification matters because the right ETL/ELT choice differs by destination. A program that uses one pattern across the whole list is forcing the wrong choice on some pipelines.
• Surface the cost-allocation question explicitly in the architecture review. Whose budget pays for transformation compute under each option? If the architecture review is happening without finance in the room, the conversation is missing its binding constraint. Get the cost-allocation answer before the architecture answer; the architecture choice is downstream.
• Bind the source-of-record to the archive, not to the pattern. Whichever pattern wins for a given pipeline, the raw data should be in a governed archive at the boundary it leaves the source system — before any transformation. The archive is the defensibility layer. The transformation choice is downstream of it. Programs that conflate the two end up with defensibility tied to whichever pattern they happened to pick.

References

• Forrester Research — The Forrester Wave™: Data Governance Solutions, Q3 2025. Report ID RES184107
• Gartner Peer Insights, market category — Augmented Data Quality Solutions. Reviewed 2026
• Gartner — Data Quality (topic page).