## TL;DR
Choose dbt when transformations need version control, testing, and documentation that analysts can own. Choose stored procedures when you need transactional control flow inside the database or when the organization already standardizes on them. Most teams end up with dbt for analytics transforms and a few stored procedures for operational jobs, and that split is a fine answer.

```text
dbt vs stored procedures: decision framework
```

## Use this when
- leadership asks why not just use stored procedures
- you are migrating legacy stored procedures to a modern stack
- you need criteria to defend a tooling choice with reasons

## Not for this skill when
- you already chose dbt and need modeling help, see the staging vs marts skill
- the question is dbt vs a specific orchestrator, that is a different comparison
- you need stored procedure syntax help, check your warehouse docs

## Steps

1. Score testability: can you verify the transform without touching production data URIs

```shell
dbt test --select fct_orders
```

Expected output: dbt runs assertions against the built models in a dev schema. Stored procedures need a hand-rolled test harness, which most teams never build, so be honest about whether yours would.

2. Score ownership: who writes, reviews, and deploys the logic in practice:

```sql
-- a stored procedure lives in the database, reviewed by whoever has DDL access
-- a dbt model lives in git, reviewed in a pull request like any other code
```

Expected output: an honest answer about your team's review culture. If analysts cannot get database deploy rights, stored procedures centralize power with whoever can, and that shapes everything downstream.

3. Score observability: how you see what ran, what failed, and what changed:

```shell
dbt run --select tag:daily
```

Expected output: per-model timing and status in the run log, plus artifacts that feed docs and lineage automatically. Stored procedures need external logging bolted on, which is another system to maintain.

4. Score portability: what happens to the investment if you change warehouses in three years:

```yaml
# dbt_project.yml targets let the same models run on dev, prod, and a new warehouse
# with adapter changes; stored procedures are rewritten per warehouse dialect
```

Expected output: a migration plan you can describe in a paragraph. dbt models move with adapter changes, stored procedures get rewritten from scratch per dialect.

5. Decide with the framework, not with vibes, and write the decision down:

```text
Pick dbt when: version control, testing, docs, and analyst ownership matter most.
Pick stored procedures when: transactional logic, in-database scheduling without
new infra, or org standards demand it.
Pick both when: analytics transforms go in dbt, operational jobs stay procedural.
```

Expected output: a written decision with reasons attached. The "both" row is the honest answer for most enterprises, and writing it down ends the debate.

## Variant phrasings

### should we replace stored procedures with dbt
Migrate the analytics transforms first, they gain the most from testing and lineage. Leave operational procedures alone until there is a real reason to touch them.

### dbt vs snowflake stored procedures
Warehouse procedures add scripting and scheduling, but the testability and review gaps remain. The framework in step 5 still applies unchanged.

### are stored procedures bad practice
No, they are a tool with a scope. Untested, unreviewed, undocumented procedures are the problem, not the concept itself.

## Why it happens
The debate recurs because both tools transform data inside the warehouse, so they look interchangeable from a distance. They are not: dbt optimizes for the analytics development loop of version, test, document, and review, while stored procedures optimize for database-native execution with transactions and control flow and no extra infra. The right choice follows from which loop your team actually lives in.

## Edge cases
- Heavily regulated industries may require all logic in audited stored procedures. Compliance beats framework elegance every time.
- Real-time or event-driven transforms fit neither tool well. That is a streaming problem wearing a batch costume.
- dbt needs somewhere to run: CI, a scheduler, or a managed service. If no compute outside the warehouse is allowed, procedures win by default.
- Migration cost is real. A thousand working procedures are not technical debt just because dbt exists, rewrite them when they hurt.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RKVzE0GJQKaYhZKtd_G1-Q