dbt Projects on Snowflake: Should You Move Your dbt Cloud Jobs In-Platform?

dbt Projects on Snowflake went GA in November 2025. It runs dbt Core natively inside your Snowflake account: the project lives in a Snowflake workspace linked to a Git repository, you develop and run it in Snowsight (or deploy it as a DBT PROJECT object), and you schedule it with tasks. No separate orchestrator, no dbt Cloud seat, no CI runner holding a Snowflake key.

If you currently run dbt Cloud jobs, the question is whether to move them in. Here is how we think about it.

What you get by moving in

• One fewer vendor and one fewer credential. The dbt project executes with Snowflake roles; there is no external service holding a key pair to your account.
• Git integration in Snowsight. Workspaces connect to GitHub, GitLab, Azure DevOps, or Bitbucket. You can edit, run, and compare in the browser, or keep developing locally and push.
• Scheduling with tasks. EXECUTE DBT PROJECT runs inside a task, so your dbt runs join the same task graph as your other orchestration, with the same monitoring in TASK_HISTORY.
• Cost lands on the warehouse. dbt compute was always Snowflake credits; now the runner's cost disappears too. For small and mid-sized teams paying per-seat for dbt Cloud, that is a real line item.
• Simpler networking. No allow-listing a vendor's IP ranges or wiring PrivateLink for a runner.

-- Deploy a project object from a workspace, then schedule it
CREATE OR REPLACE DBT PROJECT analytics.dbt_core_models
  FROM 'snow://workspace/user$.public."Analytics dbt Workspace"/versions/live/'
  DEFAULT_TARGET = 'prod';

CREATE OR REPLACE TASK analytics.dbt_nightly
  WAREHOUSE = transform_wh
  SCHEDULE = 'USING CRON 0 2 * * * America/Los_Angeles'
AS
  EXECUTE DBT PROJECT analytics.dbt_core_models ARGS = 'run --select tag:nightly --target prod';

What you give up

• dbt Cloud's platform features. The Semantic Layer, dbt Mesh cross-project references, the hosted docs site, Explorer, and column-level lineage in the dbt Cloud UI are dbt Cloud products. Snowflake gives you lineage through its own tooling (access history, Horizon), but if your analysts live in the dbt Explorer, they will notice.
• CI on pull requests. dbt Cloud's Slim CI builds only modified models into a temporary schema on every PR. You can reproduce this with a GitHub Actions workflow that calls EXECUTE DBT PROJECT with --select state:modified+, but it is your workflow to maintain.
• Cross-warehouse portability. dbt Core itself is engine-agnostic; the Snowflake-native wrapper, by definition, is not. If you run dbt against other warehouses, you will keep a second way of running it.
• Version cadence. dbt Core upgrades in dbt Projects on Snowflake arrive on Snowflake's schedule, not yours.

The workflow trade-off

The pattern we recommend is neither "all in Snowsight" nor "ignore the feature":

1. Develop locally or in Snowsight, whichever the engineer prefers — both commit to the same repo.
2. Test on pull requests in your CI system, using a CI role and a temporary schema, invoking the Snowflake-side project so the test environment matches production exactly.
3. Deploy by merging to main; a small workflow updates the DBT PROJECT object from the Git ref.
4. Schedule with tasks, tagged by domain, so each team's models run on its own warehouse and show up on its own chargeback line.

Who should move

• Teams on dbt Core with a home-built runner (Airflow, GitHub Actions cron, a VM): move. You lose nothing and retire infrastructure.
• Teams on dbt Cloud who mostly use it as a scheduler and IDE: move, and replace the CI piece with a short workflow.
• Teams on dbt Cloud who depend on the Semantic Layer, Mesh, or Explorer: stay, or run a hybrid where production runs in Snowflake and dbt Cloud remains the developer and documentation surface.

Migration in an afternoon

For a standard project: create a workspace from the repo, set the profile target to your production warehouse and role, run dbt deps and dbt build once interactively to confirm the environment, create the DBT PROJECT object, create the task, and pause the old job. Keep the old job ready to resume for one cycle.

If you want help deciding, or you want the CI workflow and task graph built to a standard, contact us. Modernizing transformation pipelines — from PowerCenter, from hand-rolled tasks, or from a dbt runner you would rather not own — is core work for our consultants.