Feature Flags & Extensibility
Relevant source files
The following files were used as context for generating this wiki page:
Feature flags and extensibility in dbt Core v2.0 (Rust) are managed through a combination of compile-time features, runtime project configurations, and tiered distribution capabilities. This architecture allows the system to support both open-source dbt Core functionality and extended analytical features provided by the Fusion engine.
The extensibility model is centered around the "Fusion" runtime, which serves as a high-performance foundation. It introduces stricter language specifications and scalable Parquet-based artifacts while maintaining backward compatibility with legacy JSON artifacts.
Sources: README.md:12-25, crates/dbt-docs-server/README.md:55-60
Tiered Distribution Model
dbt Core v2.0 utilizes a tiered approach to distinguish between baseline open-source features and advanced Fusion capabilities. This is primarily realized through artifact richness and login-based feature activation.
| Tier | Activation Method | Features Provided |
|---|---|---|
| dbt Core | Default (dbt --write-index) | Core catalog, project info, node-to-node lineage, test coverage. |
| Fusion | Authenticated (dbt login) | Column-level lineage, inferred types, sample data preview. |
Sources: crates/dbt-docs-server/README.md:55-60, README.md:46-51
The following diagram illustrates the relationship between dbt Core and the extended Fusion engine:
Project Flags and Configuration
Extensibility at the project level is controlled via dbt_project.yml flags and resource-specific configurations. These flags influence the behavior of the resolver during the parse phase.
Global Project Flags
The resolver specifically checks for flags that alter the behavior of macro validation and parser strictness:
- validate_macro_args: A boolean flag (defaults to
true) that controls whether the arguments passed to macros are validated against their definitions during the resolution phase. - static_analysis: Configuration that determines the level of static analysis performed on SQL resources, such as
Strict.
Sources: crates/dbt-parser/src/resolver.rs:188-193, crates/dbt-schemas/src/schemas/project/configs/source_config.rs:43-45
Hierarchical Configuration Overrides
The configuration system supports a "default_to" mechanism, allowing specific resource configs (like SourceConfig) to inherit and override settings from parent levels or package defaults.
Extension Interfaces (dbt-index)
The dbt-index-core crate defines abstract interfaces for proprietary feature extensions. This allows the CLI to remain source-available while enabling proprietary plugins for advanced analytics.
- Trait Surface: Provides the
Provider<Args, Output>trait andUnavailableProviderstub. - Feature Areas: Includes interfaces for
ColumnLineageProvider,ColumnImpactProvider, andArtifactMeta. - Injection: The
dbt-clicrate acts as the injection point, constructing real implementations (likeDuckDbColumnLineageProvider) and injecting them into the runtime.
Sources: crates/dbt-index-core/src/lib.rs:1-35
Compile-Time Features
Certain server-side functionalities are toggled using Rust's cargo features, particularly within the documentation server.
| Feature | Description | Default |
|---|---|---|
embed-ui | Bakes the React Single Page Application (SPA) bundle into the binary at compile time. | Enabled |
This enables a single, self-contained executable to serve both the JSON API and the interactive documentation UI without external dependencies.
Sources: crates/dbt-docs-server/Cargo.toml:19-24, crates/dbt-docs-server/README.md:27-30
Conclusion
The feature management system in dbt Core v2.0 is designed for high performance and modular growth. By combining internal configuration flags, hierarchical inheritance, and a provider-based extension model, the project maintains a clean separation between core transformation logic and advanced analytical extensions while ensuring scalability through Parquet-based artifacts.