Power Query to dbt conversion reads the let expression in M code, reconstructs dependencies between named steps, translates supported Table functions into warehouse SQL, and packages the result as dbt models with source and schema files. Paste M from the Advanced Editor or upload a .pq or .m file; direct extraction from .pbix and .pbit files isn't supported.
- Each M binding becomes a traceable SQL step, usually a CTE inside a dbt model.
- Table.NestedJoin plus Table.ExpandTableColumn becomes a join only after the expansion columns and names are resolved.
- Power Query references can point to other queries, parameters, lists, or functions; unresolved dependencies need review.
- Choose PostgreSQL, BigQuery, or Snowflake before generation so the dbt SQL uses the right dialect.
Recover the dependency chain from M
Power Query has no canvas file to walk. A query is usually a let block where each binding refers to an earlier binding, a source, or another query. Those references establish the graph. A converter has to parse them before deciding which operations belong in one model and which should become separate dependencies.
A full section document can contain several shared queries. If one query references another query in the same input, that relationship can become a dbt ref(). A missing external query stays visible as an unresolved source or dependency.
Translate Table functions into model SQL
Table.SelectRows becomes a WHERE clause, Table.AddColumn becomes a selected expression, Table.Group becomes GROUP BY, and Table.Combine becomes UNION ALL. Table.NestedJoin typically works with Table.ExpandTableColumn; the pair supplies both the join relationship and the columns that the next step expects.
- Carry renamed columns forward before translating later expressions
- Preserve join kind and expansion aliases
- Map Table.Distinct and row limits using the chosen warehouse dialect
- Flag custom functions, list-heavy transforms, and pivots that lack a safe general translation
Build the files dbt expects
The SQL body is only one artifact. A usable export also needs source declarations, model metadata, stable identifiers, and project configuration. Deflows produces model SQL plus sources.yml, schema.yml, and dbt_project.yml so the result already has a repository shape.
The scaffold doesn't decide production materializations, tests, freshness rules, or deployment jobs. Those settings depend on table size, update frequency, and the warehouse environment rather than the M expression alone.
Start with M code, not the PBIX container
Copy the query from Power BI or Excel's Advanced Editor and paste it into Deflows, or upload a .pq or .m file. A .pbix or .pbit wraps M inside a separate binary container, and the current parser doesn't extract it directly.
The dbt outputs are beta. Review types, null behavior, privacy-level assumptions, native queries, and any step that calls a custom function before committing the model.
Primary references
Questions teams ask
Can I convert a PBIX file directly to dbt?
No. Open the query in Power BI's Advanced Editor and copy the M code, or save it as a .pq or .m file. Direct extraction from the DataMashup container inside .pbix and .pbit files isn't part of the current parser.
Can Power Query references become dbt ref() calls?
Yes, when the referenced query is present in the same parsed input and can be resolved. References to missing queries or external functions remain visible for manual mapping.