ELT won. The bill for winning has arrived.

ELT beat ETL so thoroughly that the acronym argument reads like a period piece. Load raw, transform in the warehouse, version the SQL: that is simply how analytics gets built now. Reviews of settled wars are boring, so here is the interesting part: the costs the winning architecture created.

Transformation is now a warehouse workload, which means every inefficient model bills by the second on someone else's compute. The thousand-model dbt project is a real pattern in the wild, rebuilt nightly whether anything changed or not. The tooling race responded to exactly this. dbt's Fusion engine, public beta since May 2025, rewrites the core in Rust with native SQL understanding; the headline claim is parsing a 10,000-model project about 30x faster than dbt Core. Vendor number, but the direction of investment tells you where customers were bleeding.

state-aware is the actual fight

Faster parsing is nice. Not recomputing unchanged models is money. The credible architectural challenger, SQLMesh, made virtual environments and smarter incrementality its whole identity: dev environments that point views at production data instead of rebuilding it, and only changed models computed. The incumbent ecosystem versus the challenger architecture is the oldest story in tooling, and it usually ends with the incumbent absorbing the challenger's best ideas. Fusion's column-level lineage at compile time suggests exactly that ending.

where the money actually goes

We have read enough transformation bills to describe the anatomy. The largest line is the full nightly rebuild of models whose inputs did not change, which is pure superstition tax: the rebuild exists because nobody trusts the incremental logic, and nobody trusts the incremental logic because it was written once, under deadline, by someone who has since changed teams. The second line is development compute, every analyst rebuilding a personal copy of the estate to test a three-line change. The third is the long tail of models nobody queries, faithfully rebuilt for dashboards that were retired two reorganizations ago.

None of these costs shows up in the tooling debate, which is fought over parse times and DAG ergonomics. All of them show up in the invoice. A team that deletes its dead models and fixes trust in incrementality typically saves more than any engine migration will, which is not an argument against the migration, only an argument about sequencing.

the orchestration question it drags in

Transformation-in-warehouse quietly became the scheduling center of gravity for the whole platform. When the SQL DAG is the biggest DAG, the orchestrator's job collapses into triggering it and waiting, and teams reasonably ask why they run a separate scheduler at all. The tooling vendors noticed: both camps now sell hosted schedulers, column-aware triggers and freshness-based execution, each trying to absorb the orchestration budget from above or below. We reviewed the orchestrator race separately; the short version is that the transformation layer is winning the argument about who decides when things run, because it is the layer that knows what changed.

what to do this quarter

Three moves, in order of return. Put a cost per model on a dashboard; the warehouse already meters it, and the first week of visibility usually finds a model whose annual rebuild cost exceeds the salary of the analyst who owns it. Kill the dead models; lineage tools make the orphan list a query, not a project. Then, and only then, scope the engine question, because a migration priced against an honest baseline is a decision, while a migration priced against waste is a laundering.

The pattern across all three is the same. ELT moved transformation onto metered compute, and metered compute rewards teams that read the meter. The architecture war is over; the operations discipline it requires has barely started.

the review we would like to run

What the field lacks is a controlled comparison: the same thousand-model project, the same warehouse, one quarter on the incumbent engine and one on the challenger, with the bill and the incident log as the scoreboard. No vendor will fund that study for the obvious reason that one of them loses it. Until someone independent runs it, treat every headline multiplier as directional, treat your own meter as the only benchmark with jurisdiction, and treat any migration pitch that arrives without a baseline audit as what it is: a quote for repainting a house whose meter nobody has read.

The quieter conclusion from two years of watching this category is that the durable advantage was never the engine. It is the team habit of treating transformation as a costed production system rather than a folder of SQL that grew. Engines will keep leapfrogging each other; that habit compounds.

verdict

ELT: adopted, obviously, the question expired. Transformation tooling: if you are on dbt with a large project, the Fusion migration is worth scoping this year; greenfield teams should evaluate SQLMesh seriously rather than inheriting defaults. And put a cost line on your transformation jobs. The warehouse already itemizes it; most teams just decline to look.