Dbt Dry Run
You perform a dbt dry run by compiling models and checking query plans without writing tables. This process catches syntax errors and schema mismatches before your jobs alter production data. Analytics teams often run these checks using shared database roles during continuous integration builds. If those roles hold broad write rights, a bad run can still change live tables. How a dbt dry run works in your workflow Data teams build transformation pipelines by writing modular SQL templates and
Dry Run: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You perform a dbt dry run by compiling models and checking query plans without writing tables. This process catches syntax errors and schema mismatches before your jobs alter production data. Analytics teams often run these checks using shared database roles during continuous integration builds. If those roles hold broad write rights, a bad run can still change live tables.
How a dbt dry run works in your workflow
Data teams build transformation pipelines by writing modular SQL templates and Jinja macros. Before pushing changes, engineers need a safe way to check their code logic. A dbt dry run solves this by turning templates into raw SQL queries first. The tool reads your project files and links all model dependencies in memory.
Next, the workflow sends these compiled queries to the target data warehouse for validation. Instead of building tables, the runner asks the database to parse and plan each statement. The database checks that all source tables exist and column types match across joins. It also flags syntax mistakes or missing permissions before any heavy compute work starts.
Teams also use empty runs or row limits to test pipeline logic fast. In this mode, the tool builds the table structure without reading raw source rows. This step proves that downstream views and models fit together from start to finish. Engineers get fast feedback on pull requests without waiting hours for full data builds.
What native dry runs solve and what they miss
Native compilation and query planning solve the problem of broken code reaching your main branch. They stop basic SQL typos and bad model links early in the build cycle. Teams save compute costs because failed queries stop before scanning billions of table rows. Developers also gain confidence when refactoring complex dependency chains across dozens of data models.
Still, a static check only governs the code paths you tell it to test. The database setup still decides who logs in, not what individual statements do in flight. Many teams give their build runners and local profiles broad admin roles for convenience. If a developer runs a full build command by mistake, the database executes every write.
Dry Run: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, pre-deployment hooks and custom macros often run raw queries during the compilation phase itself. These helper queries can inspect live rows or alter database state outside the main plan. When engineers debug failed runs, they often query raw tables containing sensitive customer fields. Native database roles do not rewrite matched fields like emails or card numbers in results.
Managing permissions and data safety during model checks
To reduce risk, teams separate read roles from write roles across their staging setups. Pull request checks use restricted accounts that can only read source schemas and plan queries. Production write keys stay locked inside automated build servers rather than sitting on laptops. This split stops accidental table drops when an engineer tests a new model locally.
Even with split roles, managing static database keys across many team members creates toil. Engineers still need to read production schemas to understand why a model check failed. Static permissions cannot inspect single queries in flight or mask phone numbers and national IDs. Teams need finer control over every statement that leaves a laptop or build runner.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does compiling models touch the live database?
Yes, compiling often queries the database catalog to inspect table schemas and run dynamic macros. It does not build target tables, but it still needs an active database session.
How do empty runs differ from standard compilation?
Compilation only turns templates into raw SQL text on your local disk. An empty run sends queries to the database with zero rows to test schema creation.
Can a dry run catch data quality errors?
No, a dry run only checks SQL syntax, column types, and model links. You must run data tests against actual rows to catch null values or duplicates.