dbt™ Commands¶
Overview¶
Rosetta DBT Studio runs dbt™ commands for you — there's no Python environment to set up and no separate dbt™ install to manage. The app bundles its own.
To check or change the dbt™ version in use, see Settings → dbt™ Core.
Quick Reference¶
| Command | What it does |
|---|---|
| run | Builds your models into tables or views |
| test | Checks your data against the tests in your schema files |
| build | Runs and tests everything together, in dependency order |
| compile | Renders your SQL without touching the database |
| seed | Loads CSV files from seeds into the database |
| deps | Installs packages from packages.yml |
| docs:generate | Builds the project documentation and lineage graph |
| docs:serve | Opens the generated documentation |
| list | Lists the models, tests, and seeds dbt™ can see |
| debug | Checks your connection, profile, and dependencies |
| clean | Deletes generated folders such as target |
| pipeline | Runs the pipeline defined in pipeline.yml |
Building Your Models¶
run¶
Takes the SQL in each model file and creates the resulting table or view in your database.
Use it when you've written or changed a model and want the result in the database.
build¶
Runs and tests your models together, in dependency order — each model is built and tested before anything that depends on it is built.
Use it when you want the whole project done properly in one command. If a model fails its tests, dbt™ stops rather than feeding bad data into the next model.
Tip: build is the one to reach for in a real workflow. run on its own is useful while you're iterating on a single model.
Checking Your Work¶
test¶
Runs the tests defined in your schema files against the data — uniqueness, non-null columns, accepted values, and any custom tests.
Use it after run to confirm the data that landed is valid.
compile¶
Renders your model files into the exact SQL dbt™ would send to the database, without running it.
Use it when a model isn't behaving and you want to see what your Jinja and ref() calls actually resolve to. It's the fastest way to debug.
debug¶
Checks your setup — connection, profile, and dependencies — and reports what's working.
Use it first when nothing runs and you're not sure why.
list¶
Lists the resources dbt™ can see in your project: models, tests, seeds, and so on.
Use it when a model isn't being picked up — if it's not in the list, dbt™ isn't finding the file.
Managing Your Project¶
seed¶
Loads CSV files from your project's seeds folder into the database as tables.
Use it for small, static reference data that belongs in your project rather than your warehouse — country codes, category mappings, and similar.
deps¶
Installs the packages listed in your project's packages.yml.
Use it after adding a package, or when setting up a project someone else built.
clean¶
Deletes the folders dbt™ generates, such as target and dbt_packages.
Use it to clear out stale build artifacts.
pipeline¶
Runs the pipeline defined in your project's pipeline.yml.
Documentation¶
docs:generate¶
Builds the dbt™ documentation site for your project, including the model lineage graph.
docs:serve¶
Serves the generated documentation so you can browse it.
Video¶
For a walkthrough of tracking down and fixing model errors, see the official video: Debugging dbt Models in Seconds
Common Issues¶
A command fails with a connection error → Run debug first — it reports whether your connection and profile are set up correctly. Then check the connection on the Database Connections screen.
A model isn't being built
→ Run list to confirm dbt™ can see it. If it's missing, check the file is saved and sitting in the models folder.
Changes to a model aren't showing in the database → Save the file, then run the model again. Use compile to check the SQL dbt™ is actually generating.
A package isn't found
→ Run deps to install the packages listed in packages.yml.
Tests fail after a successful run → The models built, but the data didn't meet the conditions in your schema files. Check the test output for which column and which test failed.