📘Introduction

In this hands-on dbt tutorial, you’ll learn how to switch between development (DEV) and production (PROD) environments using target variables in dbt. You’ll see how to dynamically control where your models are built, and easily run commands against different data warehouses — all without changing a single line of SQL.

🎓 Preparing for dbt Analytics Engineering Certification?
Check out our exam study guide packed with practical examples and hands-on tutorials:

➡️📕 dbt Analytics Engineering Certification Guide

↔️ DEV and PROD environments in dbt

Before we dive in, have a look at our previous post:

Configuring DEV an PROD Environments in dbt
📘Introduction In this hands-on dbt tutorial, you’ll learn how to configure separate development (DEV) and production (PROD) environments to safely build, test, and deploy your data models. We’ll walk through why environment separation matters and how to configure your profiles.yml so you can switch between environments with

In that tutorial, you learned how to configure separate DEV and PROD environments in dbt.
Now, we’ll take it a step further and show how to switch dynamically between those environments using dbt’s built-in target variable.

💡What are target variables in dbt?

The target variable is a built-in Jinja object in dbt that provides metadata about the active connection to your target warehouse. It contains information such as:

Attribute Description Example
target.name The name of the active target. Commonly used to distinguish environments like dev or prod. dev
target.schema The default schema where dbt will build models for the current target. Can be overridden in model configs. analytics_dev
target.database The database connected to for the active target. Useful when working across multiple environments or databases. DLNERDS_UNIVERSITY_DEV
target.threads The number of parallel threads dbt uses to execute models for the current target. Controls build concurrency. 4

You can use the target variable inside your modelsmacros, and configuration files (e.g., dbt_project.yml), and even dynamically execute dbt commands for a specific environment.

This allows you to control where your models are built, manage schema naming conventions, and apply environment-specific logic — all without changing your project files.

⚙️ Target variable in our example project

First, let's have a look at the profiles.yml in our example project:

You can view this post with the tier: Academy Membership

Join academy now to read the post and get access to the full library of premium posts for academy members only.

Join Academy Already have an account? Sign In