sqlbuild_project.toml- shared project configuration, committed to version controlsqlbuild_local.toml- local developer overrides, gitignored
sqlbuild_project.toml
A complete example:Required fields
Connection
Theconnection block is passed directly to the adapter. For DuckDB:
Targets
A target is a named build context - the schema, database, or connection you build against (for exampledev and prod). Targets let you build to different places from the same project. Each target can override:
Selecting a target
The active target is determined by (in order of precedence):--targeton the command line (highest priority)sqlbuild_local.tomltargetfielddefault_targetinsqlbuild_project.toml- No target (models build to the default schema)
Clone policies
Targets can declare whether they allow cloning to or from:Defaults
Project-wide model defaults. Any field you can set in aMODEL() header can be set here as a default:
MODEL() header.
Path defaults
Per-directory model defaults. Useful for applying different config to different parts of your project:models/staging/stg_orders.sql matches the models/staging path default.
Config layering order
Configuration is layered in this order, with later layers overriding earlier ones:- Project defaults (
defaults) - Path defaults (
path_defaults) - if the model’s path matches - MODEL() header - the model’s own config
tagsare unioned across layers. A model withtags [marts]in its header that matches a path default withtags [managed]will have both tags.row_diff_exclude_columnslists are unioned across layers.row_diff_tolerancesmappings are deep-merged across layers, so a header tolerance for one column adds to (rather than replaces) tolerances declared in defaults or path defaults.
Settings
Global feature toggles:Table promotion mode
staged(default for most adapters): Materializes into a staging table, runs audits, then swaps into the target. If audits fail, the production table is untouched.direct: Creates the table directly at the target location. Audits run after materialization. Simpler but no pre-promotion safety net.
Project variables
Variables are simple string substitutions available in model SQL via the@@name syntax:
Janitor
Configuration for thesqb janitor command, which cleans up stale warehouse relations:
Scenario
Configuration for scenario snapshot capture safety limits and local type overrides:
Local type overrides for DuckDB replay are configured per adapter dialect:
dbt
Configuration for running SQLBuild alongside an existing dbt project:
Paths can be absolute or relative to the SQLBuild project root. See Using SQLBuild with dbt for setup and usage details.
Skills
Configuration for AI agent skill file installation:
See skills CLI reference for usage details.
sqlbuild_local.toml
Local developer overrides. This file should be gitignored.
This replaces the common dbt pattern of switching profiles or setting environment variables to change targets. Each developer sets their target, connection, and preferences once in
sqlbuild_local.toml and it persists across sessions.
