What Is a dbt Model?
A dbt model is nothing more than a single .sql file containing a SELECT statement that defines a transformation on top of your raw data. dbt takes that SELECT statement, wraps it in the appropriate DDL/DML for your warehouse, and creates a view or table from it — you never write CREATE TABLE or CREATE VIEW yourself.
Cricket analogy: Just as a batsman only needs to focus on where to hit the ball while the scoreboard operator handles the arithmetic, a dbt author only writes the SELECT logic while dbt handles the CREATE TABLE plumbing.
Writing Your First Model
-- models/staging/stg_customers.sql
with source as (
select * from {{ source('raw', 'customers') }}
),
renamed as (
select
id as customer_id,
first_name,
last_name,
lower(email) as email,
created_at
from source
)
select * from renamedEach model lives in exactly one .sql file inside the models/ directory, and the filename itself becomes the name of the resulting table or view — a file named stg_customers.sql produces a relation called stg_customers. Models are typically organized into layers such as staging, intermediate, and marts, and they reference each other using the ref() function rather than hardcoded table names.
Cricket analogy: Just as each player on a T20 team has one specific batting slot in the order, each dbt model occupies one specific file and one specific name in the DAG, with no ambiguity about its role.
Model Configuration
Configuration for a model can be set inline at the top of the .sql file using the config() Jinja macro, specifying options like materialized, schema, or tags, and these inline settings override anything set in dbt_project.yml. This lets you keep model-specific overrides close to the model itself while still having sensible project-wide defaults.
Cricket analogy: This is like a captain setting a general fielding strategy for the whole match but calling a specific field change, like bringing in a slip, for just one particular bowler's over.
The config() block can also be set for an entire directory of models at once inside dbt_project.yml, so you rarely need to repeat the same materialized: table setting in every file.
Folder Structure and Organization
dbt projects conventionally split models into staging (one-to-one cleanup of a raw source), intermediate (reusable joins and business logic that aren't meant to be queried directly), and marts (final, analyst-facing tables). This layered structure keeps transformation logic modular and makes the DAG easier to reason about as the project grows.
Cricket analogy: This is like the structure of a cricket academy that separates raw talent intake, intermediate net-practice drills, and finally the polished first-team squad ready to play international matches.
Avoid querying raw source tables directly from marts models — always route through a staging model first, even if it feels redundant for a simple table, so cleanup logic lives in exactly one place.
- A dbt model is a .sql file containing a single SELECT statement; dbt generates the CREATE TABLE/VIEW DDL for you.
- The filename of the model becomes the name of the resulting database relation.
- Models reference each other via ref(), never via hardcoded, environment-specific table names.
- Configuration can be set inline with config() in the file, overriding project-wide defaults in dbt_project.yml.
- The staging → intermediate → marts folder convention keeps transformation logic modular and easy to navigate.
- Always route raw source access through a staging model rather than querying sources directly from downstream models.
Practice what you learned
1. What determines the name of the table or view a dbt model produces?
2. Which layer of a typical dbt project performs one-to-one cleanup of a raw source table?
3. Where can a model's materialized config be overridden for a single file?
4. Why should downstream marts models avoid querying raw source tables directly?
Was this page helpful?
You May Also Like
ref() and source() Functions
Learn how dbt's ref() and source() functions build the project's dependency graph and enable environment-safe, portable SQL.
Materializations: View, Table, Incremental
Understand how dbt's view, table, and incremental materializations trade off build cost against query performance, and when to use each.
Jinja Templating in dbt
Learn how dbt uses the Jinja templating engine to add loops, conditionals, and variables to plain SQL, turning static queries into reusable, environment-aware code.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
ProgrammingPowerShell Study Notes
Programming · 30 topics