What is dbt (conceptually)?

Someone on the team says “just put it in dbt.” You nod. You open a repo full of folders named staging, intermediate, and marts. Half the files are SQL. A few YAML files shout about tests you never wrote. The dashboard still works. You still do not know what “dbt” actually is, or why your SQL in a notebook is not the same thing. That gap is normal. This part closes it without turning into an install tutorial.

This is Part 5 of How data actually moves. Parts 1 through 4 covered the path from source to serve, batch versus stream, where data lives, and orchestration. dbt sits in the transform layer for many modern warehouses: SQL models, tests, and docs that travel with the code. You still need solid SQL (SQL series), quality habits (Data quality), and clear metrics (Metrics that matter). For the full AMS map, see Learn.

What you’ll learn

What dbt is (and is not) in plain English
How SQL models, tests, and docs fit together
Why teams use staging, intermediate, and marts layers
Why analysts should care even if they never run dbt run
A worked mini project shape with a table and sample SQL
Common mistakes and a practice plan for this week

dbt in one sentence

dbt (data build tool) is a way to turn warehouse SQL into a managed project: each model is a SELECT that builds a table or view, dependencies are declared in the SQL, tests and documentation live next to the models, and a command line (or cloud runner) builds them in the right order.

It is not a database. It is not an orchestrator for every job in the company. It is not a BI tool. It does not replace Python for weird one-offs, and it does not magically clean bad source data. It is a transform framework optimized for analytics SQL that many people will share, review, and schedule.

If you already write SQL against Snowflake, BigQuery, Redshift, Databricks SQL, Postgres, or similar engines, dbt is mostly a project structure and a compiler around the SQL you already know. The warehouse still stores the data. dbt tells the warehouse which models to create and in what order.

Rule of thumb: If the value is “we ran the same transformation twice and got different answers,” dbt is about versioned, testable transforms. If the value is “we never loaded the file,” fix landing and orchestration first (Parts 1 and 4).

The three pieces analysts actually meet

1. Models (SQL that builds tables or views)

A model is usually one .sql file whose body is a SELECT. dbt materializes that query as a table or view in the warehouse. You reference other models with a special function (often written like ref('orders_clean')) so dbt knows the graph: build A before B.

That graph is the big upgrade from a folder of random scripts. When someone asks “what feeds the revenue mart?” you follow ref() edges instead of guessing which notebook ran last Tuesday.

2. Tests (assertions on the built data)

Tests are checks that run against the warehouse after (or as part of) a build. Common built-in ideas:

Unique on a primary key column
Not null on required fields
Accepted values for status codes
Relationships so foreign keys point at real parents

Teams also write custom SQL tests (“yesterday’s order count should not drop more than 40% versus the prior same weekday”). Conceptually this is the same spirit as the validation series: cheap, clear, tied to consumers. dbt’s contribution is packaging tests next to the model so “shipping a metric” and “shipping the checks for that metric” stay in one pull request.

3. Docs (definitions that sit with the code)

YAML next to models can describe tables, columns, and owners. Generated docs sites turn that into browsable lineage and descriptions. Perfect docs are rare. Useful docs are possible: grain of the model, what “active customer” means here, and who to ping when the test fails.

If your company also has a catalog tool, treat dbt docs as the engineering-facing source of truth for transforms, and the catalog as the discovery layer. They should not invent two different definitions of revenue.

Staging, intermediate, marts: why the folders exist

Most dbt projects layer models so each stage has one job. Names vary. The idea does not.

dbt three layers: staging cleans sources, intermediate joins and logic, marts serve BI. The warehouse still stores the data.

Staging (source-shaped, cleaned lightly)

Staging models usually sit one step above raw sources. Rename columns to a house style. Cast types. Light filter of obvious junk. Keep grain close to the source system. Goal: a stable, readable base so nobody joins the raw dump forever.

If five analysts each rename cust_id differently, you get five silent join bugs. Staging is where you agree once.

Intermediate (building blocks, not the final story)

Intermediate models join staged pieces, apply business rules, or reshape data for reuse. They are the workshop tables: useful for debugging, not always what executives open. A good intermediate model has a clear grain and a name that says what it is (int_orders_with_customers), not a joke only three people understand.

Marts (consumer-ready facts and dimensions)

Marts are what BI tools and metric dashboards should prefer. One grain per model. Names that match how the business talks. Fewer columns of intermediate debris. This is where “orders by day by channel” or “active accounts snapshot” should live.

When Part 6 of this series talks about environments, marts are the tables you are most careful promoting. When Part 7 talks about freshness and volume, marts are the first boards you watch.

Layer	Job	Who should query day to day?	Typical fail mode
Staging	Clean, rename, type-cast sources	Transform owners; rarely exec dashboards	Skipping staging and joining raw forever
Intermediate	Reusable joins and logic	Analysts debugging logic	Hiding final metrics only in intermediate
Marts	Stable, documented consumer tables	BI, self-serve, metric reviews	Five marts for the same KPI with different filters

Why analysts should care (even if DE owns the repo)

You might never click “deploy dbt Cloud.” You still inherit the outcomes.

Definitions stop living only in Slack. Column descriptions and tests force someone to write “what is a paid order?” near the code that computes it. That is metric hygiene with a build step (see Metrics that matter).
Lineage becomes navigable. When finance’s number disagrees with marketing’s, the first question is not “who is right?” It is “which models and filters differ?”
Your one-off SQL can graduate. A notebook that saves the company monthly should not stay a private hero script. Staging through marts is a promotion path for logic that matters.
Tests fail before the meeting. Unique key and not-null failures are early news, the same idea as automated checks in the quality series.
Review culture improves numbers. Pull requests on SQL beat “I fixed it in prod at 11pm” for institutional memory.

Python still matters for profiling, charts, and pipelines that are not pure SQL transforms (Python for analytics). dbt does not cancel notebooks. It gives shared warehouse logic a home that is not someone’s desktop.

What dbt is not (so you set expectations)

Not a full EL stack. Landing files, CDC, and API extractors live elsewhere. dbt assumes data is already in the warehouse (or reachable as a source).
Not the only way to schedule work. Something must call dbt build or equivalent: Airflow, Dagster, dbt Cloud jobs, cron. That is Part 4 territory.
Not automatic governance. Access control, PII policies, and legal holds are separate. dbt can document and test; it cannot replace stewardship (Phase H on this site’s plan).
Not a substitute for grain discipline. A beautiful project with wrong grain still ships wrong dashboards. Foundations and quality still apply.
Not a free pass to skip code review. Bad SQL at scale is still bad SQL. The framework multiplies both good and bad habits.

Worked example: a tiny orders path

Imagine raw tables already landed: raw.orders and raw.customers. The business wants a daily revenue mart by channel, with tests on order ids and non-null amounts. Here is a conceptual shape (names simplified; not a full project install).

Mini dbt model graph: stg_orders and stg_customers feed int_orders_enriched, which feeds fct_revenue_daily mart, with…

Staging model sketch for orders (illustrative SQL body only):

SELECT
  order_id,
  customer_id,
  CAST(order_ts AS TIMESTAMP) AS order_ts,
  LOWER(TRIM(channel)) AS channel,
  CAST(amount AS NUMERIC) AS amount,
  UPPER(TRIM(status)) AS status
FROM {{ source('app', 'orders') }}
WHERE order_id IS NOT NULL;

An intermediate model might join customers and filter to paid statuses. A mart aggregates to day and channel:

SELECT
  DATE(order_ts) AS order_date,
  channel,
  COUNT(*) AS order_count,
  SUM(amount) AS revenue
FROM {{ ref('int_orders_enriched') }}
WHERE status = 'PAID'
GROUP BY 1, 2;

Conceptual YAML for tests on the staging model (schema tests, not a full file):

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: amount
        tests:
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['PAID', 'PENDING', 'CANCELLED', 'REFUNDED']

What that project shape buys you Monday morning:

Question	Without layered models	With staging → intermediate → marts
Where is channel cleaned?	Buried in five dashboard queries	`stg_orders` once
Why is revenue low?	Re-open three notebooks	Check tests, then mart SQL, then intermediates
Can marketing self-serve?	Maybe, with wrong filters	Prefer `fct_revenue_daily` with docs
Did paid filter change?	Git archaeology on random files	PR on the intermediate or mart

Notice you did not need a vendor bake-off to understand the design. The value is structure, tests, and shared definitions. Install details, adapters, and cloud vs core are for a later how-to when your team is ready.

How to read a dbt change as an analyst

You may not own the repo, but you will review outcomes. When someone opens a pull request that touches “your” metric, use a short checklist:

Which models changed? Staging-only renames are lower risk than mart filter changes.
Did grain change? One row used to mean one order; now it means one order line. That is a meeting, not a silent merge.
Did tests change? Removing a unique test without a story is a smell. Adding tests is usually good news.
Is the metric spec still true? If paid orders now include a new status, the published definition and dashboard footnote should move with the SQL.
What is the before and after on a known day? Ask for a side-by-side total for last Tuesday in stage. Numbers beat vibes.

This is how analysts participate without needing admin rights: you own the business meaning, you insist on comparable checks, and you refuse surprise grain shifts. That partnership is why dbt culture works when it works. When it fails, it is usually because transforms shipped without a consumer in the loop.

If your team has no formal PR process yet, still write the five bullets above into a ticket before a “quick prod fix.” The point is shared memory, not ceremony.

How dbt fits the series so far

Part 1 path: dbt lives mainly in transform, after land, before or beside serve.
Part 2 latency: dbt models often run on a batch schedule (hourly, nightly). Streaming needs different patterns; do not force every real-time dream into a nightly mart.
Part 3 storage: warehouses are the usual home; lakes and lakehouses can host similar ideas with different tooling.
Part 4 orchestration: dbt is a node in a larger DAG, not always the whole DAG. Upstream extract failures still break your beautiful models.

If your “dbt job” is green but raw tables are empty, you have an orchestration and source problem, not a mart design problem. Keep the layers honest.

Common mistakes

Treating dbt as magic BI. It builds tables. People and tools still build charts and decisions.
One giant model for everything. Un-debuggable SQL that only one person dares edit. Split layers.
Skipping tests “until later.” Later never comes. Ship three tests on the most blamed table first.
Marts that still look like raw dumps. Consumers then reinvent cleaning in every dashboard.
Copy-pasting the same business logic in five models. Intermediate exists so you fix once.
Documenting nothing. Then arguing weekly about grain. Write one sentence of grain per mart.
Letting analysts only query raw forever. Bypasses the project and reintroduces chaos.
Assuming dbt replaces quality culture. Tests without owners and response habits become noise (Part 7 and the quality series).

How to practice this week

Pick one number you report weekly. Write its grain and filters in plain English (metric spec style).
Find where that number is built today: dbt model, scheduled SQL, notebook, or dashboard calc.
If you have a dbt repo, open the lineage for that mart and list staging and intermediate parents. Sketch the same graph on paper if you do not have docs site access.
Propose one test that would have caught last quarter’s scare (unique key, not null amount, accepted status).
Stop a new one-off from becoming permanent: if you re-run the same SQL thrice, file a ticket to promote it into a shared model.
Read your warehouse’s model names with the three-layer lens. Note anything labeled “final” that is still source-shaped.

Quick recap

dbt is a transform project framework: SQL models, tests, and docs, built against your warehouse.
Models form a dependency graph so builds and debugging follow real lineage.
Staging cleans sources, intermediate holds reusable logic, marts serve consumers.
Analysts care because definitions, review, and promotion of logic become visible work.
dbt is not extract, not full orchestration, and not a substitute for grain or quality habits.
Next: environments, why laptop truth is dangerous, and who can write prod (Part 6).

Sources

Research and further reading used for this article:

dbt Labs: Introduction to dbt (what dbt is and how models fit analytics engineering)
dbt Labs: About dbt models (SQL models, materializations, and ref thinking)
dbt Labs: Data tests (generic and singular tests next to models)
dbt Labs: How we structure our dbt projects (staging, intermediate, and marts guidance)
dbt Labs: Documentation (descriptions and docs generation with the project)
Analytics Made Simple: SQL series (query skills that power warehouse models)
Analytics Made Simple: Data quality (checks and dimensions that pair with dbt tests)
Analytics Made Simple: Learn (paths across foundations, pipelines, and more)