More on the topic...
Generating detailed summary...
Failed to generate summary. Please try again.
SQLBuild plugs into your existing dbt project and makes builds change-aware. It fingerprints every model, seed, function and Python node, then skips anything that hasn’t changed. If you point it at a production branch or target, it can clone unchanged tables instead of rebuilding them, saving compute and dev time. No edits to your dbt files. No new SQLBuild models. You just install the package, run sqb dbt build and it drives the dbt CLI as a subprocess.
All state lives in your warehouse alongside your data. SQLBuild writes append-only tables (_sqlbuild_fingerprints, _sqlbuild_node_results, etc.) so there’s no external state machine, no manifest files, and no paid service. Full table builds land in staging until all audits pass, while incremental models validate each microbatch before merging. Audit rules live inline, blocking bad data before it reaches production.
You still write plain SQL files with a MODEL() header and a SELECT block. References use __ref() and __source(), and SQLBuild validates your SQL, infers columns, checks contracts and computes lineage before any query runs. It also supports Python loader functions (@loader) and @task, @asset or @check nodes in the same DAG. For CI, you can run unit tests that mock sources, and end-to-end scenarios in local DuckDB without touching your warehouse.
Getting started takes minutes. pip install sqlbuild, then sqb playground waffle-shop to try the sample project. Point SQLBuild at your dbt_project.yml, run sqb dbt build --select path:models/marts, and see it skip unchanged models on the next run. It works on DuckDB, MotherDuck, Snowflake, BigQuery, Databricks, PostgreSQL and SQL Server today, with ClickHouse, Redshift, Trino, Spark and Athena coming soon. Full docs live at docs.sqlbuild.com.
Questions about this article
No questions yet.