Environments and connections

Every workspace talks to your data warehouse through connections, and those connections are organized into environments. Understanding this split explains most of what an Admin configures in Settings.

​

Why environments exist

You don’t want a work-in-progress model overwriting a production table. Environments keep the two worlds apart:

• Development environment: used by the Code IDE. When you run a model while developing, it builds into your development schema, safely away from production data.
• Scheduler environment: used by Bolt. Production runs build into your production schema with production credentials.

Each environment has its own connection: warehouse credentials, target database or dataset, and schema. Same project code, different targets. Paradime also uses dedicated connections for specific jobs:

• Cost connection: read-only access Radar uses to analyze warehouse spend.
• DinoAI agent environment: the connection background agents use when they work on your project.

​

What a connection contains

A connection is the set of details dbt™ needs in its profiles.yml, managed for you in the UI: adapter type (Snowflake, BigQuery, Redshift, and others), credentials, target schema, and any optional connection attributes your adapter supports.

​

The git side

Your code has environments too. Development happens on branches in the Code IDE; production runs from your default branch. The git repository connection is what lets Paradime clone, commit, and open pull requests on your behalf.

​

Where to go next