Cloning objects between environments with dbt clone

The dbt clone command creates lightweight clones of upstream models into your current target schema, using database-native cloning (e.g., zero-copy clone) where supported, or view-based fallback otherwise. It is primarily used to speed up CI/CD workflows and development by avoiding full rebuilds of unchanged models, cloning them from a stateful state (like the prod manifest) instead. This is closely tied to dbt's state-based selection (--state) and deferral features.

1 · Learn the must-know

• 1dbt clone requires a --state flag pointing to a manifest.json from a previous run, typically production, to know what to clone.
• 2It works hand-in-hand with state:modified selection, allowing unchanged models to be cloned instead of rebuilt, saving compute and time in CI jobs.
• 3On platforms that support zero-copy cloning (e.g., Snowflake, Databricks), clones are fast, storage-efficient, and use native CREATE ... CLONE or CREATE TABLE ... LIKE mechanics; other adapters fall back to creating views pointing to the original relation.
• 4Cloned relations are created in the current target schema/database as defined by your target, not in the original schema, enabling isolated environments like CI schemas.
• 5dbt clone is distinct from --defer: deferral only resolves refs to unbuilt upstream nodes at compile time without creating anything, whereas clone actually materializes a cloned relation in your target.
• 6Common gotcha: cloning does not re-run tests or freshness checks on the cloned model, so you must still validate that the source state is trustworthy (e.g., a recent successful prod run).

2 · Check your understanding