Skip to main content
Point SQLBuild at your existing dbt project to stop rebuilding it from scratch in dev. No SQLBuild models, no migration, no edits to your dbt files. It adds two things on a plain dbt project:
  • Reuse from production. Building a branch in dev usually rebuilds the whole project, even though most models are identical to production. SQLBuild compiles a production-shaped git branch, copies its already-built tables into your target, and seeds incremental models from a production baseline, so dbt only builds what your branch actually changed. See Reuse from production.
  • Change-aware builds. SQLBuild fingerprints your dbt models in the warehouse and prunes the ones that have not changed, so a second build skips everything already current. See Change-aware builds.
SQLBuild reads your dbt manifest and drives the dbt CLI as a subprocess. It never edits, patches, or moves files in your dbt project, and it does not reimplement Jinja, profiles, or dbt’s selection language. Your dbt project runs exactly as it does today.

​
Start with your existing dbt project

From inside your dbt project, run a sqb dbt command. Selection works exactly like dbt: scope to whatever you would normally build with --select, or omit it to plan the whole project. 
sqb dbt plan --select path:models/marts
The first time you do this, SQLBuild bootstraps itself. If there is no sqlbuild_project.toml, it reads your dbt_project.yml and profile and creates a minimal twin project in a sqlbuild_project/ directory next to your dbt project. It reuses your dbt profile for the warehouse connection, so there are no separate credentials to configure. 
my-workspace/
  analytics/                  # your existing dbt project, untouched
    dbt_project.yml
    models/
    target/
      manifest.json
  sqlbuild_project/           # created by SQLBuild
    sqlbuild_project.toml     # points at the dbt project, no models of its own
The generated sqlbuild_project.toml looks like this: 
name = "analytics"
adapter = "snowflake"
default_target = "dev"

[dbt]
project_dir = "../analytics"
profiles_dir = "/Users/you/.dbt"
target_path = "../analytics/target"
target = "dev"

[targets.dev]
schema = "analytics"

[targets.dev.connection]
source = "dbt_profile"
profile = "analytics"
target = "dev"
source = "dbt_profile" tells SQLBuild to connect using your dbt profile, so it talks to the same warehouse dbt does. Run sqb dbt build --select path:models/marts once to build your selected dbt models with state recorded, then plan again. Once everything in the selection is current, the dbt side reports nothing to do: 
Plan ready (0 selected resources)

dbt (3 selected resources)
  selected by dbt selector: 3 from dbt selector
  planned models: 0 run, 3 current, 0 blocked
  planned non-model dbt work: 0
  skipped: all planned dbt models are current

  Model plan
    First run (0)
    Current (3)
      model.analytics.dim_customers   no change
      model.analytics.fct_orders      no change
      model.analytics.dim_products    no change
    Blocked (0)
The next sqb dbt build skips the dbt run entirely because nothing changed. Change one model and only that model, plus whatever depends on it, rebuilds.

​
How it works

  1. SQLBuild runs dbt compile to produce a manifest.json with model metadata
  2. SQLBuild reads the manifest to understand dbt model names and their qualified warehouse tables
  3. SQLBuild resolves your --select/--exclude against dbt by running dbt ls, so dbt-native selectors like state:modified and package: are evaluated by dbt itself, not reimplemented
  4. SQLBuild plans which dbt models actually need to run, using warehouse-stored fingerprints and source freshness, and optionally reuses already-built relations from production
  5. sqb dbt plan/run/build/test orchestrates the run: dbt builds only the models that changed, pruning everything that is current
  6. (Optional) any SQLBuild models you have added run last, against the dbt outputs
Each step calls the dbt CLI directly: dbt compile for the manifest, dbt ls for selection, and dbt build/dbt run for execution.

​
Configuration

The auto-generated project above is editable, and you can write sqlbuild_project.toml by hand. The [dbt] block (shown in the generated project above) accepts:
FieldDescription
project_dirPath to the dbt project root (where dbt_project.yml lives)
profiles_dirPath to the directory containing profiles.yml
target_pathPath to dbt’s target/ directory (where manifest.json is written)
targetdbt target name override (optional)
replay_on_changeProject-wide policy for rerunning changed dbt models: forward_only (default) or full (optional). See Change-aware builds.
reuse_fromProduction reuse configuration (optional). See Reuse from production.
Paths can be absolute or relative to the SQLBuild project root.

​
Prerequisites

  • dbt must be installed and available on PATH
  • Both projects must target the same warehouse and schema/database context
SQLBuild runs dbt compile automatically as part of sqb dbt plan/run/build/test to produce the manifest. You do not need to compile the dbt project manually.

​
On this topic

  • Selection - how --select and --exclude route work across both graphs.
  • Reuse from production - pull already-built tables from a production-shaped git branch instead of rebuilding.
  • Change-aware builds - fingerprinting, cascade propagation, source freshness, and pruning unchanged dbt models.
  • Adding SQLBuild models - optionally write SQLBuild models, tests, audits, and scenarios downstream of dbt.
  • Testing and debug - mock dbt refs in unit tests, sqb dbt test, and sqb dbt debug.