Zero-Copy Cloning

Analogy categoryAnalogies

What Makes Cloning 'Zero-Copy'?

Zero-copy cloning uses the CREATE ... CLONE syntax to produce a full logical copy of a table, schema, or entire database that initially shares the same underlying micro-partition files as the source, rather than physically duplicating bytes. Because Snowflake's storage layer is immutable and metadata-driven, a clone is essentially a new pointer structure referencing the same physical data, which makes the operation nearly instantaneous regardless of whether the source is a 10-row table or a 50-terabyte database.

🏏

Cricket analogy: It's like the DRS system generating a duplicate ball-tracking overlay from the same raw Hawk-Eye camera feed instead of re-filming the delivery from scratch.

Cloning Tables, Schemas, and Databases

CLONE works at three levels of granularity: a single table with CREATE TABLE ... CLONE, an entire schema with CREATE SCHEMA ... CLONE which recursively clones every table, view, and stage inside it, and a full database with CREATE DATABASE ... CLONE which recursively clones every schema. Object-level grants are not automatically copied to the clone by default, so a clone of a governed production dataset typically needs its own set of privileges applied unless you clone within a scope where inherited role grants already cover the new object.

🏏

Cricket analogy: Cloning a database is like duplicating an entire tournament bracket, including every group stage and knockout match, not just copying one scorecard.

sql

-- Clone a single table for testing
CREATE TABLE orders_dev CLONE orders;

-- Clone an entire schema, including all tables, views, and stages
CREATE SCHEMA analytics_dev CLONE analytics;

-- Clone a full database from a Time Travel point for a safe sandbox
CREATE DATABASE prod_snapshot_20260709
  CLONE prod_db
  AT(TIMESTAMP => '2026-07-09 23:59:59'::timestamp);

-- Re-grant privileges on the clone since grants are not copied automatically
GRANT SELECT ON ALL TABLES IN SCHEMA analytics_dev TO ROLE analyst_role;

Storage Costs and Divergence

A clone incurs no incremental storage cost at creation time because it references the same micro-partitions as the source. Costs only appear as the clone and source diverge: once either side inserts, updates, or deletes rows, Snowflake writes new micro-partitions for the changed data while unchanged partitions continue to be shared, so storage grows in proportion to how much the two datasets actually differ, not the total size of the object. This makes cloning ideal for spinning up dev/test environments from production data without doubling storage bills.

🏏

Cricket analogy: It's like two teams starting a Test match from the identical pitch conditions, but the pitch only 'changes' where actual play — bowling footmarks, wear — occurs on each side.

Cloning combined with a Time Travel AT or BEFORE clause is a common pattern for creating a point-in-time snapshot — for example, cloning a database as it existed right before a risky migration ran, so you have an instant rollback target without pausing production.

Clones do not automatically inherit future or existing object-level grants outside of role-based inheritance; verify privileges on cloned objects before handing them to another team, especially when cloning production data into a less-restricted dev environment, since sensitive data is fully present in the clone unless masking policies also apply.

CLONE creates an instant logical copy that initially shares the same micro-partitions as the source, incurring no immediate storage cost.
Cloning works at table, schema, and database granularity, with schema/database clones recursively including all nested objects.
Storage costs only grow as the clone and source diverge through inserts, updates, or deletes on either side.
Object-level grants are not automatically copied to clones and typically need to be reapplied.
Combining CLONE with AT/BEFORE lets you create a point-in-time snapshot for safe testing or pre-migration rollback points.
Cloned data carries the same sensitive content as the source unless masking or row access policies also apply to the clone.
Zero-copy cloning is ideal for spinning up dev/test/staging environments from production-scale data cheaply and instantly.