System Design · easy

What is the difference between a staging model and a mart in dbt, and why keep them separate?

Asked in Analytics Engineer interviews, in the System Design round.

Short answer

Staging is one-to-one with a source: rename, cast, and clean only — no business logic, no joins. Marts are the joined, business-shaped tables analysts query. Separating them means a source change is absorbed in one place, logic is reusable across marts, and each layer's contract can be tested on its own.

How to answer it

Staging is where the source is made usable; marts are where the business questions are answered. Keeping them apart is what lets either change without breaking the other.

A staging model is one-to-one with a source table. It renames columns to the project's conventions, casts types, trims strings, fixes timezones, and nothing else. No joins, no business logic, no filtering beyond removing obvious junk. It is a view or a light table.

-- stg_shop__orders.sql
select
  id            as order_id,
  customer_id,
  cast(created_at as timestamp) as ordered_at,
  status,
  total_cents / 100.0 as total_amount
from {{ source('shop', 'orders') }}

A mart is the joined, business-shaped table an analyst queries: fct_orders joined to customers and products, dim_customer with segments, a daily revenue rollup. It encodes definitions and is where the business logic lives.

Why separate:

• A source change (a renamed column, a new type) is absorbed in one staging model; every mart on top of it keeps working.
• Business logic is written once in the mart and reused, rather than re-derived from raw columns in every downstream query.
• Each layer can be tested on its own contract: staging tests are about shape (not null, unique id); mart tests are about meaning (revenue reconciles, one current row per customer).
• Intermediate models between the two hold the reusable joins and are the place complexity goes when a mart gets long.

The rule of thumb: if a query needs to know what the source system called a column, it is doing staging's job.

• What they are checking: "one-to-one with the source, no business logic" for staging, and the change-isolation argument.
• Common mistake: a staging model that already joins customers to orders, so the next mart cannot reuse either half.

Related questions

• Design a data pipeline to ingest 1B events/day.
• Batch vs streaming: how do you decide for a given use case?
• A nightly pipeline fails halfway through. How do you design it so re-running is safe?
• Events can arrive up to 48 hours late. How do you handle that in a daily aggregation?
• When would you denormalize a warehouse table, and what do you give up?
• Design a data warehouse schema for an e-commerce company.

Practice this for real

• Check your resume against a Analytics Engineer job description — free, no account needed.
• Every data interview question, by role and topic
• Scored AI mock interviews — two free, no card