Environments and Deployment

Analogy categoryAnalogies

A dbt environment is a named combination of a warehouse connection, a target schema, and a set of variables that determines where models get built and which data they read from. The same dbt project — the same .sql files and the same dbt_project.yml — can run against a developer's personal dev schema, a shared staging schema used for CI validation, and a production schema that BI tools query, purely by switching which target or environment is active, without changing a single line of model code.

🏏

Cricket analogy: It's like the same batting technique being applied in a domestic Ranji Trophy match, an IPL match, and a Test match — same skill, different stage and stakes, just as the same dbt code runs in dev, staging, and prod with different consequences.

Targets and Schema Isolation

In dbt Core, environments are defined as targets within profiles.yml, each specifying its own schema, and often its own database or warehouse size; developers typically default to a dev target that builds into a personal schema like dbt_jsmith so individual work never collides with a teammate's. In dbt Cloud, this is modeled explicitly as Environments in the project settings — a Development environment tied to the IDE, and one or more Deployment environments (commonly staging and production) each with their own connection, custom schema, and environment variables, so a job assigned to the production environment always writes to the production schema regardless of who triggers it.

🏏

Cricket analogy: It's like each player having their own personal practice net (dev schema) while the main square (production schema) is reserved for the actual match, so a net session never damages the pitch used on match day.

Promoting Changes Through Environments

A safe deployment flow runs the same dbt build command against increasingly production-like environments: a developer iterates locally or in the Cloud IDE against dev, opens a pull request that triggers a CI job building into a temporary or staging schema to validate the change in isolation, and only after review and a green CI run does a merge to the main branch trigger the production deployment job that builds into the schema BI tools actually query. dbt Cloud environments also support deferral, where a job can defer unbuilt or unchanged nodes to the state of a previous production run instead of rebuilding the entire DAG, which keeps CI runs fast even on large projects.

🏏

Cricket analogy: It's like a batter's technique change being validated in the nets, then a warm-up match, before it's trusted in an actual Test innings — each environment is a gate the change must pass before the next.

yaml

# profiles.yml with dev and prod targets
my_dbt_project:
  target: dev
  outputs:
    dev:
      type: bigquery
      project: my-warehouse-dev
      dataset: dbt_jsmith
      threads: 4
    prod:
      type: bigquery
      project: my-warehouse-prod
      dataset: analytics
      threads: 8

# invoked as:
# dbt build --target dev    (local development)
# dbt build --target prod   (production deployment job)

dbt Cloud's deferral feature (--defer combined with --state) lets a CI job reuse the production run's already-built unchanged models instead of rebuilding the whole DAG, so a pull request touching two models doesn't have to rebuild all 400 models in the project to validate those two.

An environment is a combination of warehouse connection, target schema, and variables — the model code itself never changes across environments.
dbt Core defines environments as targets in profiles.yml; dbt Cloud models them explicitly as Development and Deployment environments.
Each developer typically works in a personal dev schema to avoid colliding with teammates.
A safe promotion flow moves changes through dev, then a CI/staging build, then production, each gated by review or passing checks.
Deferral lets CI jobs reuse a previous production run's unchanged models instead of rebuilding the entire DAG.
Production environments in dbt Cloud are tied to specific schemas regardless of who triggers the job.
Environment variables can vary warehouse size, credentials, and schema names without touching model SQL.