Build Daily
Tinley Park · October 21, 2026dbt Vs. Stored Procedures! Should You Migrate Your SQL to dbt?
This video runs a real head-to-head comparison of dbt versus stored procedures on Postgres, converting a 20-step nightly procedure into six dbt models and evaluating testing, lineage, recovery, and code review to help data engineers decide whether to migrate. It opens with a 2 am failure scenario and closes with an honest verdict on when each approach wins.
The outline
Tap a timestamp to jump there in the video.
Step 14 of 20 failed at 2am
The video opens with a 2 am incident where a nightly stored procedure fails at step 14 of 20, leaving steps 1–13 already committed and raising the question of whether a simple rerun is safe.
What a stored procedure really is
A stored procedure is defined as an imperative list of steps that mutate tables, committing changes as it goes.
How a dbt model works: SELECT plus ref()
A dbt model is explained as a declarative SELECT that describes what a table should contain, with ordering handled by ref() and source().
Steps vs state: the real difference
The core distinction is drawn between a procedure's step-by-step imperative execution and dbt's state-based, idempotent model approach.
Converting INSERT, UPDATE, DELETE and MERGE
A 20-step procedure is converted into six dbt models following dbt's migration guide: INSERT becomes a model, UPDATE a CASE expression, DELETE a filter, and MERGE an incremental model with a unique_key.
Head-to-head: testing and lineage
Testing and lineage are compared head-to-head, showing how dbt's built-in tests and automatic lineage tracking differ from the manual effort required for stored procedures.
Recovery: rerunning the failed night
Rerunning the failed night is demonstrated: the stored procedure doubles a day's revenue because it re-applies committed steps, while the dbt retry produces the correct result.
Code review and CI
Code review and CI/CD integration are contrasted, highlighting how dbt's file-based models fit naturally into pull-request workflows versus monolithic procedure scripts.
When stored procedures still win
Two categories of stored procedures are identified where dbt should not replace them, acknowledging that some procedural logic is better left as-is.
dbt's escape hatches: hooks and run-operation
dbt's escape hatches—hooks and run-operation—are introduced as ways to retain procedural behaviour when a pure model is not sufficient.
The verdict: migrate or keep?
A final verdict is delivered on whether a given workload should be migrated to dbt or kept as a stored procedure.
Recap
The key takeaways from the comparison are recapped in a concise summary.
Honest limits
The creator lays out the honest limits of the comparison, noting what the video does and does not cover and where the analysis may not generalise.
A 20-step procedure that commits steps 1 through 13 then dies at 14 leaves every downstream dashboard empty, and the question of whether it is safe to just run it again is the one a solo operator actually faces at 2am with no one to page. Converting that into six tested models with lineage and recovery is less a tooling preference and more about making the system idempotent enough that one person can trust a re-run. The honest verdict that each approach wins in different contexts keeps the decision grounded for a builder weighing migration cost against the risk of a single point of failure.