Five engines, one table dbt · OneLake · AEMO
The same dbt gold layer, built on five engines into one OneLake lakehouse. The business logic is identical; what differs is the dialect and what each engine and adapter will actually do.
Recent runs
dbt promises that the engine is abstract: a model is a SELECT, the adapter does the rest, and changing --target gets the same table somewhere else. For the business logic that holds. The eight models compute the same numbers on all five engines, and Parity checks it on every run.
What does not abstract away shows up on every model, and it is not the axis people expect. Whether an engine is distributed or single-node barely matters: nothing in the five copies of a model cares that Spark has executors and DuckDB has one process.
What matters is the dialect (Syntax), and what each engine, adapter and catalog actually implements: which merge shapes the catalog accepts, whether the adapter honours a config or silently ignores it, how a CSV can be read at all, whether there are hooks (Engines).
When an engine or adapter gets it wrong, the bug is filed upstream (Bugs).
The engines: duckrun (DuckDB writing Delta via delta-rs), iceberg (dbt-duckdb into the OneLake Iceberg REST catalog), ducklake (dbt-duckdb, DuckLake with its catalog in a Fabric SQL DB, plus a Delta export), spark (dbt-spark on local PySpark, Delta) and polars (dbt-polars, Polars SQL, Iceberg via pyiceberg).
More: the thesis, engine nuances, candidate engines, and the dbt DAG and catalog.