dbt clone: zero-copy clones, pointer views and CI

1.What dbt clone creates in your target

dbt clone copies objects from one environment into another without running any model SQL. It arrived in dbt v1.6, alongside dbt retry, as part of a set of features for running mature deployments at scale. You point it at the artifacts of another run with --state, typically the manifest.json from a production job. dbt then works out where each selected node lives in that environment and creates a matching object in the schema(s) of your current target. The command uses a dedicated clone materialization, and the object it produces depends on two things: the warehouse you are on and what the source object is.

Zero-copy cloning only happens when both conditions hold. The warehouse must support zero-copy cloning of tables (Snowflake, Databricks or BigQuery), and the node must exist as a table in the source environment. In that case dbt creates a clone that shares the underlying storage, so no data is duplicated. If either condition fails, for example on a warehouse without zero-copy cloning or for a model that is a view in production, dbt creates a pointer view: select * from the source object. A pointer view is cheap to create, but every query against it still reads the production relation.

By default, dbt clone leaves existing relations alone. If your dev schema already contains fct_orders from last week's work, a plain dbt clone --state ... skips it and clones only what is missing. That default protects work in progress, but it also means stale objects stay stale. To replace everything in the selection with a fresh clone of the source state, add --full-refresh. Selection works the same way it does for other commands: --select limits the clone to particular nodes. Each clone statement is independent of the others, so raising --threads well above your usual run setting shortens a large clone.

# clone all of my models from specified state to my target schema(s)
dbt clone --state path/to/artifacts

# clone one_specific_model of my models from specified state to my target schema(s)
dbt clone --select "one_specific_model" --state path/to/artifacts

# clone all of my models from specified state to my target schema(s) and recreate all pre-existing relations in the current target
dbt clone --state path/to/artifacts --full-refresh

# clone all of my models from specified state to my target schema(s), running up to 50 clone statements in parallel
dbt clone --state path/to/artifacts --threads 50

Sources12

2.When to clone and when to defer

dbt clone is built on deferral but costs more than deferral. Deferral, covered with state selection in [state and deferral](lesson:7.1), rewrites the ref calls for unselected nodes so they point at production, and it creates nothing extra. dbt clone does create objects. It uses some warehouse compute and leaves new relations in your schema. In many cases deferral is the cheaper and simpler choice. Clone earns its cost when something outside dbt needs to find real objects in your schema.

Each of these situations needs real objects in the target:

- Blue/green continuous deployment, on warehouses that support zero-copy cloning of tables. - Cloning the current production state into development schemas, so a dev environment is populated without running the full pipeline. - Handling incremental models in CI jobs, on warehouses that support zero-copy cloning. - Testing code changes on downstream dependencies in a BI tool, which can only query objects that exist in the warehouse.

The BI case shows the difference most clearly. Deferral only changes how dbt compiles SQL, so a dashboard pointed at your dev schema finds no tables there. After a clone, the dashboard can query the dev schema directly. The same reasoning applies to promotion. Because clone creates lightweight copies across environments, it can move specific models from a staging environment into production.

How you set up defer depends on where you run clone. In the dbt platform CLI, dbt clone includes --defer automatically, so the command works with no extra setup. The Studio IDE needs three things first: a Production environment with at least one successful job run, the Defer to production toggle switched on in the lower-right corner of the command bar, and then the dbt clone command run from the command bar.

Sources12

3.Cloning incremental models in slim CI

A slim CI job builds into a fresh PR-specific schema, and incremental models do not handle that well. A typical job defers to production, runs dbt build --select state:modified+, and is triggered by every pull request against main. Suppose a PR modifies dim_wizards. The job builds dim_wizards and its downstream fct_orders into a temporary schema created for that PR.

That full rebuild causes two problems. Incremental models are usually the largest datasets in a project, so rebuilding them on every PR is slow and expensive. The rebuild also tests the wrong path. A full refresh can pass in CI even when the incremental run in production will fail after merge. The fix is to clone the pre-existing incremental models into the PR schema before the build runs. When dbt build starts, those models already exist, is_incremental is true, and CI runs the same code path that production will. This only works on warehouses with zero-copy cloning. Anywhere else, the clone step produces pointer views.

dbt clone --select state:modified+,config.materialized:incremental, ? 

The comma-separated selector is an intersection, and each part has a job. state:modified+ picks modified models and everything downstream of them. config.materialized:incremental keeps only the incremental ones. state:old drops nodes that are new in this PR. A brand-new incremental model has nothing in production to clone, and it will run as a full refresh once merged, so CI should run it as a full refresh too. Without state:old, the command still works but logs "No relation found in state manifest for…". Adding state:old states the intent explicitly. The second step is the usual dbt build --select state:modified+.

Cloning also brings schema-change failures into CI, and you need to decide how to handle them. Consider an incremental model with on_schema_change='fail' and a PR that adds a column. An incremental build of that model fails, while a full refresh succeeds. With the clone step in place, CI fails the way production will after merge. The alternative is a green CI check followed by a failing nightly dbt build. dbt Labs prefers the failing CI job: someone manually overrides the branch protection rule and then runs dbt build --full-refresh --select my_incremental_model in production right after merge.

{{
    config(
        materialized='incremental',
        unique_key='unique_id',
        on_schema_change='fail'
    )
}}

Sources3

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.dbt clone always produces zero-copy clones of production tables.Why is that wrong?

   Zero-copy clones need both a warehouse that supports them (Snowflake, Databricks, BigQuery) and a table in the source environment. In every other case dbt creates a pointer view.

   Covered in What dbt clone creates in your target

2. 2.Running dbt clone again refreshes every object that is already in the dev schema.Why is that wrong?

   Pre-existing relations are skipped by default. Only --full-refresh recreates them.

   Covered in What dbt clone creates in your target

3. 3.dbt clone is the cheaper replacement for --defer.Why is that wrong?

   Clone uses compute and creates objects. Deferral is often cheaper and simpler, and clone is worth it only when real objects are needed, for example for a BI tool.

   Covered in When to clone and when to defer

4. 4.Cloning incremental models in CI makes them run incrementally on any warehouse.Why is that wrong?

   The strategy depends on zero-copy cloning. On other warehouses the clone step creates pointer views instead.

   Covered in Cloning incremental models in slim CI