All posts
dbt

Why You Should Use `virtualenv` for Local dbt Development

Avoid version conflicts and dependency issues when using dbt by isolating environments with virtualenv.

CBCaryle Blondell
3 minutes read

Why You Should Use virtualenv for Local dbt Development

Setting up a local environment for working with dbt (Data Build Tool) can feel deceptively simple—just install it with pip and go, right? Not quite. If you're switching between projects that use different versions of dbt or different adapters (like dbt-postgres, dbt-snowflake, or dbt-bigquery), you can quickly run into dependency conflicts. That’s where virtualenv becomes essential.

In this post, we'll explore why isolating your dbt environment with virtualenv is a best practice and how to do it.

The Problem with Global Python Installs

dbt is released as a Python package, and like most Python tools, it relies on a specific set of dependencies. But those dependencies can change drastically between:

  • Major dbt versions (e.g., dbt v1.7 vs v1.9)
  • Adapter packages (e.g., dbt-postgres might not play nicely with dbt-snowflake)
  • Plugin tools like dbt-expectations, dbt-utils, or even IDE plugins

Installing everything globally using pip install dbt-core or pip install dbt-snowflake may work once—but as soon as you switch to another project with different requirements, you risk breaking your entire setup.

Enter virtualenv: Your Isolated Sandbox

A virtual environment is a self-contained directory that contains its own Python binaries and packages, separate from the global environment.

Benefits:

  • Version isolation: Use dbt v1.5 in one project, v1.9 in another.
  • Adapter separation: Keep dbt-snowflake in one env, dbt-postgres in another.
  • No system pollution: Avoid modifying your system Python install or clashing with other Python tools.
  • Safe experimentation: Test dbt plugins or custom macros without risk.

With virtualenv, you can easily pin and install a specific version of dbt and its adapter, such as:

pip install dbt-snowflake==1.9.0

Or for PostgreSQL:

pip install dbt-postgres==1.9.0

This is especially helpful when working across teams or environments where version consistency is critical.

How To Set Up dbt with virtualenv

1. Install virtualenv (if you haven't already):

pip install virtualenv

2. Create a virtual environment:

virtualenv venv-dbt-postgres

3. Activate the environment:

macOS/Linux:

source venv-dbt-postgres/bin/activate

4. Install dbt with the desired adapter:

pip install dbt-postgres==1.9.0

5. Verify it works:

After installation, you can immediately test the setup by running:

dbt

You should see the dbt CLI output with available commands like init, run, build, etc., confirming that dbt-postgres==1.9.0 is properly installed and working.

pip freeze > requirements.txt

Now your team or future self can recreate this exact environment with:

pip install -r requirements.txt

Bonus: Use direnv or Makefile for Easy Activation

If you work in multiple dbt projects, you can automate virtualenv activation with direnv or create a simple Makefile to handle setup.

Example Makefile:

setup:
	python3 -m venv .venv
	source .venv/bin/activate && pip install -r requirements.txt

Using virtualenv when developing with dbt isn't just a nice-to-have—it's essential if you want to avoid version conflicts, adapter collisions, and broken environments. Whether you're a solo analytics engineer or working across teams, isolating your dbt setup with virtualenv ensures consistency, reproducibility, and peace of mind.

With just a few commands, you can safely install and run any version of dbt and its adapter—like dbt-postgres==1.9.0—and immediately start working by running:

dbt

No more conflicts. No more surprises. Just clean, consistent dbt environments every time.