Supported features beta
Learn about the features supported by the dbt Fusion engine, including requirements and limitations.
info
The dbt Fusion engine is currently in beta and the related documentation is a work in progress. The information on this page will evolve as features are added and enhanced. Join the conversation in our Community Slack channel #dbt-fusion-engine.
Parity with dbt Core
Our goal is for the dbt Fusion engine to support all capabilities of the dbt Core framework, and then some. Fusion already supports many of the capabilities in dbt Core v1.9, and we're working fast to add more.
Note that we have removed some deprecated features, and introduced more-rigorous validation of erroneous project code. Refer to the Upgrade guide for details.
Requirements
To use Fusion in your dbt project:
- You are using a supported data warehouse and authentication method.
- Have only SQL models defined in your project. Python models are not currently supported because Fusion cannot parse these to extract dependencies (refs) on other models.
Limitations
If your project is using any of the features listed in the following table, you can use Fusion, but you won't be able to fully migrate all your workloads because you have:
- Models that leverage specific materialization features may be unable to run or may be missing some desirable configurations.
- Tooling that expects dbt Core's exact log output. Fusion's logging system is currently unstable and incomplete.
- Workflows built around complementary features of the dbt platform (like model-level notifications, Advanced CI, and Semantic Layer) that Fusion does not yet support.
note
We will move quickly to implement as many of these features during the Beta period and ahead of General Availability. Read more about the path to GA.
Feature | This will affect you if... | GitHub issue |
|---|---|---|
| Cloud CLI configuration (DWH credentials, environment variables) | You have a dbt platform account, you want to develop locally with the Fusion CLI, and you do not have profiles.yml configured locally. Use dbt init for a guided profile-setup experience. In the future, Fusion will use DWH connections configured in the dbt platform to reduce duplicative/divergent configuration. | dbt-fusion#23 |
| Exposures (including "auto" + "active") | You use the exposure: selection method, or trigger refreshes of downstream exposures during DAG orchestration. Note that dbt jobs that have docs generate checked, including jobs running on Fusion, will continue to produce metadata about exposures and show them in Catalog lineage. | dbt-fusion#13 |
| --store-failures | You use the --store-failures feature of dbt test to materialize the results of test queries in audit tables. | dbt-fusion#15 |
| "clone" command | You use the clone command to set up development or CI environments. Fusion does support deferral, as an alternative to cloning. Alternatively, you can keep running CI jobs on dbt Core, you can clone schemas via run-operation, or manually in your DWH. | dbt-fusion#22 |
| Unsupported materializations: microbatch incremental strategy, materialized views, dynamic tables, custom materializations | You are configuring models with materializations other than view, table, or incremental. You cannot yet run those models with Fusion, but you can run models using the standard materializations. | dbt-fusion#12, dbt-fusion#17, dbt-fusion#27 |
| query-comment | You rely on prepended or appended SQL comments with dbt model metadata to analyze queries. | dbt-fusion#20 |
| --warn-error, --warn-error-options | You are upgrading all/specific warnings to errors, or silencing specific warnings, by configuring the warning event names. Fusion's logging system is incomplete and unstable, and so specific event names are likely to change. | dbt-fusion#8 |
| Advanced CI ("compare changes") | You use the "compare changes" feature of Advanced CI in the dbt platform. | dbt-fusion#26 |
| "Model governance" (contracts/constraints, access ref restrictions (private in groups + protected in packages), deprecation_date warnings) | If you have models configured with enforced model contracts, or to template constraints (PK/FK/etc) in the data platform, Fusion does not yet support these features. If you have models in groups configured with access: private, Fusion does not yet restrict references to those models by models in other groups. Fusion also does not yet restrict references to private/protected models in projects with restrict-access: true if the project is installed as a package dependency. (This restriction does apply for project dependencies in dbt Mesh.) If you have models with set deprecation_date, Fusion does not yet raise warnings about upcoming/past deprecations. Fusion’s logging system is currently incomplete and unstable. | dbt-fusion#25 |
| grants | You have specified the grants config so that, when those models run, dbt will ensure that the specified recipients have the specified privileges. Fusion does not yet support grants. | dbt-fusion#24 |
| Iceberg support (across adapters) and "catalogs" (new feature in dbt Core v1.10) | You have configured models to be materialized as Iceberg tables, or you are defining catalogs in your project to configure the external write location of Iceberg models. Fusion does not yet support these model configurations. | dbt-fusion#28, dbt-fusion#37 |
| Logging system | You have scripts, workflows, or other integrations that rely on specific log messages (structured or plaintext). At present, Fusion’s logging system is incomplete and unstable. It is also not our goal to provide full conformance between dbt Core logging and Fusion logging. | dbt-fusion#7 |
| Model-level notifications | You are leveraging the dbt platform’s capabilities for model-level notifications in your workflows. Fusion currently supports job-level notifications. | dbt-fusion#7 |
| retry | Fusion does not yet support the dbt retry CLI command, or "rerun failed job from point of failure." In deployment environments, using state-aware orchestration, you can simply rerun the job and Fusion will skip models that do not have fresh data or have not met their freshness.build_after threshold since the last build | dbt-fusion#21 |
| --empty and --sample (new dbt Core v1.10 feature) | You use the --empty flag for "dry runs" in dev/CI, or the --sample flag for runs with limited data. You can still use Fusion, just not in these runtime modes. We intend to implement support for --sample using Fusion's native SQL comprehension. You may find that --empty is unnecessary, because Fusion can statically validate model SQL without running any models, and Fusion can also execute unit tests without requiring "empty" DWH objects for column schema introspection. | dbt-fusion#34 |
state:modified.<subselector> methods | You rely on granular "subselectors" because state:modified is insufficiently precise. Fusion’s state detection is smarter out-of-the-box; give it a try! | dbt-fusion#33 |
| dbt-docs documentation site and "docs generate/serve" commands | Fusion does not yet support a local experience for generating, hosting, and viewing documentation, as dbt Core does via dbt-docs (static HTML site). We intend to support such an experience by GA. If you need to generate and host local documentation, you should continue generating the catalog by running dbt docs generate with dbt Core. | dbt-fusion#9 |
| Programmatic invocations | You use dbt Core’s Python API for triggering invocations and registering callbacks on events/logs. Note that Fusion’s logging system is incomplete and unstable. | dbt-fusion#10 |
| Semantic Layer: development + saved_query exports | If you actively develop new semantic objects (semantic_models, metrics, saved_queries), or change existing objects in your dbt project, you should do this with dbt Core rather than Fusion, because Fusion does not yet produce semantic_manifest.json (the interface to MetricFlow). If you use the "exports" feature of saved queries, this is not yet supported in Fusion, so you should continue running your jobs on dbt Core. | dbt-fusion#40 |
| Custom snapshot strategy | You use a custom snapshot strategy other than the two built-in options: timestamp and check | dbt-fusion#44 |
| Linting via SQLFluff | You use SQLFluff for linting in your development or CI workflows. Eventually, we plan to build linting support into Fusion directly, since the engine has SQL comprehension capabilities. In the meantime, you can continue using the dbt Core + SQLFluff integration. dbt Cloud will do exactly this in the Cloud IDE / Studio + CI jobs. | dbt-fusion#11 |
{{ graph }} - raw_sql attribute (e.g. specific models in dbt_project_evaluator) | You access the raw_sql / raw_code attribute of the {{ graph }} context variable, which Fusion stubs with an empty value at runtime. If you access this attribute, your code will not fail, but it will return different results. This is used in three quality checks within the dbt_project_evaluator package. We intend to find a more-performant mechanism for Fusion to provide this information in the future. | TK |
More information about Fusion
Fusion marks a significant update to dbt. While many of the workflows you've grown accustomed to remain unchanged, there are a lot of new ideas, and a lot of old ones going away. The following is a list of the full scope of our current release of the Fusion engine, including implementation, installation, deprecations, and limitations:
0