From an Empty Folder to a Table
A dbt project is a folder with a dbt_project.yml in it. Everything else — models, macros, tests — is convention that file points at. Your credentials deliberately live somewhere else entirely.
Chapter 1 argued for dbt. This chapter builds something with it: an empty directory, one command, some configuration, and a table in the warehouse that dbt created. By the end you will have run five commands and be able to explain what every one of them did.
Start with the shape of what `dbt init` produces. Most of these files you will never touch; three of them you will touch constantly. Select each one below to see which is which.
A dbt project is a folder with a dbt_project.yml in it. Everything else — models, macros, tests — is convention that file points at. Your credentials deliberately live somewhere else entirely.
Setup is where most people lose their first day with dbt, and almost always to the same three things: a profile name that does not match, a YAML indentation error, or running from the wrong directory. None of those are conceptually hard, but each produces an error message that points somewhere unhelpful. Recognising them on sight is worth more than any amount of modelling theory in week one.
- dbt_project.yml
- The file whose presence defines a project. dbt walks up from your working directory looking for it, and gives up at the filesystem root. It names the project, names the profile to connect with, and sets folder-level defaults.
- profiles.yml
- Connection credentials. Lives outside the project by default, at ~/.dbt/profiles.yml, so it is never committed and can be reused across every project on the machine.
- Adapter
- The plugin that teaches dbt to speak one warehouse’s dialect — dbt-snowflake, dbt-bigquery, dbt-databricks, dbt-postgres, dbt-duckdb. Installed separately from dbt itself.
- Target
- A named set of connection settings within a profile — typically `dev` and `prod`. The same models build into different places depending on which target is active.
$ pip install dbt-core dbt-duckdb # engine + one adapter
$ dbt init wavelength_analytics # scaffold the project
Running with dbt=1.12.0
Your new dbt project "wavelength_analytics" was created!
$ cd wavelength_analytics
$ dbt debug # prove the connection works
All checks passed!
$ dbt build # build models, run their tests
Completed successfully
Done. PASS=3 WARN=0 ERROR=0 SKIP=0 TOTAL=3Installing `dbt` from PyPI and expecting it to connect to your warehouse. dbt-core has no database drivers of its own. Without the matching adapter package you get an error about an unknown type at the first command that touches the connection — install `dbt-core` and `dbt-<your-warehouse>` together.
Use DuckDB for your first project even if your company runs Snowflake. It removes credentials, networks and cost from the learning loop entirely, and every concept transfers unchanged.
Pin your dbt version in the project from day one. “It broke and nobody changed anything” is almost always a version that moved underneath a CI image.
Run `dbt debug` before you believe any other error message. Half of all early dbt problems are connection problems wearing a different costume.
`dbt init` leaves two example models in models/example/. Delete them once you have run them successfully — they exist to prove the setup works, and leaving them in place is the first small piece of clutter in a project that will accumulate plenty on its own.
A folder with dbt_project.yml in it is a dbt project. Credentials live outside it, on purpose, and that single separation explains most of this chapter.
