How to Get Started with dbt Cloud

dbt Cloud is a managed web platform for running dbt (data build tool), the open-source framework used by data teams to write, test, and schedule SQL-based transformation models. Unlike dbt Core, which requires a local Python environment and command-line setup, dbt Cloud runs entirely in the browser and connects directly to a cloud data warehouse. A team with no prior dbt experience can sign up and run their first transformation model in under 30 minutes.

What dbt Does and Why Teams Use It

Most organizations store raw operational data in a cloud data warehouse such as BigQuery, Snowflake, or Redshift. That raw data is usually messy: column names are inconsistent, timestamps are in different formats, and tables contain rows that need to be filtered or joined before they are useful for analysis.

dbt's role is to manage the transformation layer between raw data and the clean tables that analysts, dashboards, and automated reports consume. Each transformation is written as a SQL SELECT statement in a .sql file. dbt compiles those files, determines the correct execution order based on declared dependencies, and runs them against the warehouse. The output is a set of clean tables or views that replace hand-coded SQL scripts stored in spreadsheets or shared drives.

According to dbt Labs, more than 50,000 companies used dbt as of 2024, a number that has grown as cloud data warehouses became cheaper and more accessible to organizations outside of large enterprises.

dbt Core vs dbt Cloud

dbt Core is the open-source, command-line version. It requires a working Python environment (Python 3.8 or higher), a virtual environment, and configuration files edited by hand in a text editor. For an experienced engineer, setup takes under an hour. For an analyst without a Python background, it can take a full day of troubleshooting dependency conflicts and PATH issues.

dbt Cloud wraps the same underlying engine in a browser-based IDE. There is no local software to install. The platform handles Git integration, job scheduling, and documentation hosting as managed services. The trade-off is cost: the Developer plan is free for one user, but the Team plan costs $100 per user per month, and larger organizations move to enterprise contracts.

For teams where analysts rather than engineers own the transformation layer, dbt Cloud removes the most common friction points in getting started.

Step 1: Create a Free Account

Go to cloud.getdbt.com. Sign up with an email address or Google account. The Developer plan is free and covers a single user with unlimited models, tests, and job runs. No credit card is required for the free tier.

After signing up, dbt Cloud prompts you to create a new project and select a warehouse connection type.

Step 2: Connect Your Warehouse

dbt Cloud supports Snowflake, BigQuery, Redshift, Databricks, Azure Synapse, and several others. The connection form asks for credentials specific to your warehouse:

For Snowflake, you need your account identifier (in the format orgname-accountname), a database name, a warehouse compute cluster, and either a username and password or a key-pair.

For BigQuery, you upload a service account JSON file downloaded from the Google Cloud Console. The service account needs BigQuery Job User and BigQuery Data Editor roles on the target project.

For Redshift, you provide the host endpoint, database name, port, and a username and password.

If you are testing without an existing warehouse, BigQuery Sandbox is the fastest entry point: it requires no credit card, provides 10 GB of free active storage and 1 TB of free query processing per month, and a service account can be created and downloaded in under five minutes from the Google Cloud Console.

Step 3: Initialize a Project

After connecting a warehouse, dbt Cloud creates a default project structure and links it to a Git repository. You can use GitHub, GitLab, or Bitbucket, or use dbt Cloud's managed Git to start without a separate repository.

The key directories in the project:

models/ holds SQL transformation files. Each file is a SELECT statement that becomes a table or view in your warehouse.

tests/ holds data quality test definitions that run after each build.

seeds/ holds CSV files that dbt can load directly into the warehouse as tables, useful for static lookup tables like country codes or product categories.

macros/ holds reusable Jinja functions that any model can call.

The dbt_project.yml file at the root sets the project name, warehouse connection, and default materialization: whether your models produce views (faster to rebuild, no storage cost) or tables (faster to query, uses warehouse storage).

Step 4: Write and Run Your First Model

In the dbt Cloud IDE, click the plus icon in the file tree under models/ to create a new file. Name it stg_orders.sql. A model file is a plain SELECT statement with a dbt source reference so dbt knows where the raw data comes from:

SELECT
  order_id,
  customer_id,
  order_date,
  status,
  total_amount
FROM {{ source('raw', 'orders') }}
WHERE status != 'cancelled'

Next, create a sources.yml file in the same folder to define the raw source:

version: 2
sources:
  - name: raw
    database: your_database
    schema: raw_data
    tables:
      - name: orders

Run the model by typing dbt run --select stg_orders in the command bar at the bottom of the IDE. dbt compiles the SQL and executes it against your warehouse. For a table with a few thousand rows, the first run completes in under 30 seconds. The result is a new view or table in your warehouse that downstream tools can query directly.

Step 5: Add Data Quality Tests

dbt's built-in tests catch data problems before they reach reports or dashboards. The four built-in tests are unique, not_null, accepted_values, and relationships. They are defined in YAML files next to your models.

Add a test file for stg_orders:

version: 2
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ['pending', 'shipped', 'delivered']

Run dbt test --select stg_orders. dbt executes a query for each test and reports the number of failing rows. In a scheduled job, test failures can be configured to stop the run and trigger an alert notification to a Slack channel or email address.

Step 6: Schedule a Job

In the dbt Cloud interface, navigate to Deploy then Jobs. Click Create Job and configure:

A name for the job, such as "Nightly Transformation Run."

The commands to run in sequence, typically dbt run followed by dbt test.

A schedule using a cron expression. A daily run at 6:00 AM UTC is a common starting point: 0 6 * * *.

dbt Cloud sends email notifications on job failures and maintains a full run history, including the compiled SQL for each model, execution time, and row counts. This log is useful for diagnosing failures without needing to access the warehouse directly.

Step 7: Generate Project Documentation

Run dbt docs generate in the IDE command bar. dbt queries the warehouse to collect column-level metadata and combines it with any descriptions added in YAML files to produce a documentation site.

Click the book icon in the IDE header to open the generated docs. The site includes a searchable list of every model, source, and test in the project, along with a lineage graph showing how data flows from raw sources through transformation models to final outputs.

For teams with more than three or four contributors, the documentation site becomes one of the most-used parts of dbt in practice. Analysts can check what a column means, trace where a number comes from, and verify that a test exists for a field before using it in a report, without asking a colleague.

Practical Starting Points and Costs

The free Developer plan is sufficient for a single analyst running daily transformations on one project. For teams sharing models across multiple contributors, the Team plan at $100 per user per month adds role-based access control, multi-user environments, and SSO.

dbt Labs publishes a free Fundamentals course at courses.getdbt.com that covers models, sources, testing, and documentation in approximately four hours. The course uses dbt Cloud and a provided BigQuery dataset, requiring no local setup or personal warehouse account.

For teams building on a cleaned dbt output layer, tools like VSLZ let users query that structured data in plain English and generate charts from a single prompt, which can reduce the gap between a finished transformation model and a shareable report.

The dbt community Slack at getdbt.com/community has over 70,000 members as of 2025, with channels organized by warehouse type, use case, and experience level. For questions that go beyond the official documentation, the community is the fastest path to a working answer.