Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Snowflake zero-copy cloning creates a new database, schema, or table that initially shares the source’s existing micro-partitions rather than making a full copy of its data. The clone and source can then change independently, but later writes, retained historical data, and certain table types can use additional storage. That makes cloning useful for development, testing, and point-in-time recovery—not a guarantee of a permanently free, fully independent backup.
What is Snowflake zero-copy cloning?
Zero-copy cloning is Snowflake’s method for creating a derived object that initially references the source’s existing data storage. For standard tables, the shared units are micro-partitions. Snowflake’s TABLE_STORAGE_METRICS documentation describes cloned tables as sharing underlying storage until the original or clone is modified.
The source and clone have separate identities and can be changed independently. This is useful when you need a working copy of production data for development or testing, or want to create an object representing an available historical state. The initial sharing avoids a full data copy, but it does not make the clone an immutable backup or remove the need to review its behavior.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesHow do you clone a Snowflake table?
Snowflake uses the CREATE ... CLONE command. A basic table-clone pattern is:
#1 Best Overall
CREATE TABLE my_table_clone CLONE my_table;Replace the example names with names appropriate to your database and schema, and ensure your role has the required privileges. The command supports cloning databases, schemas, tables, and selected other schema objects; exact options depend on the object. See Snowflake’s CREATE <object> … CLONE reference for object-specific syntax.
Supported database, schema, and non-temporary table clones can use AT or BEFORE to select a Time Travel point, provided the required history remains available. A historical clone cannot be created if the object did not yet exist or the necessary history has been purged.
Rank #2
Does Snowflake cloning use storage, and are clones free?
The initial standard clone does not require another full copy of the source’s existing micro-partitions. After either object changes, Snowflake may create new micro-partitions associated with the object that owns the changed data. As a result, a clone’s storage footprint can grow after writes, and source-side changes or retained data can affect storage accounting too.
Clones can be created from other clones, and each object has its own lifecycle. Deleting or changing the original does not mean every byte associated with the clone lineage disappears immediately: retained data can continue to contribute to storage use. The relevant question is how many bytes have changed and remain retained, not simply how many clone objects exist. Snowflake explains these effects in its storage-cost guidance and data storage considerations.
For investigation, administrators can use Snowflake’s TABLE_STORAGE_METRICS view to examine storage metrics and clone-group information. Snowflake also points to BACKUP_STORAGE_USAGE for backup storage. These are useful starting points for understanding storage; no single metric should be treated as an automatic calculation of every charge attributable to a clone.
What changes when you clone a database or schema?
A cloned container is not necessarily a ready-to-run duplicate of the source environment. Before using it, check these object-specific behaviors described in Snowflake’s cloning considerations.
Rank #4
- Privileges: Most clone statements do not copy explicit grants unless the applicable
COPY GRANTSoption is used. Grants on containing objects also need review. - Streams: Unconsumed records in streams included in a database or schema clone are inaccessible in that clone. For ordinary cloning, the clone’s table history starts at clone time.
- Tasks and alerts: Tasks and alerts cloned as part of a database or schema are suspended by default. Decide whether and when they should run in the clone.
- Retention: Historical cloning depends on available Time Travel data for the relevant objects. A child table with shorter retention can limit the historical point available for a database or schema clone. In applicable cases,
IGNORE TABLES WITH INSUFFICIENT DATA RETENTIONallows unavailable tables to be skipped. - Long-running clone operations: DML during a long clone operation and zero-day retention can make required data unavailable. Snowflake advises avoiding source DML during the operation where practical or ensuring retention temporarily, then restoring the intended settings carefully.
A Time Travel clone represents historical data at the selected point, but metadata can have different timing behavior. Do not assume it reproduces every aspect of the environment exactly as it existed then.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How are standard clones different from clones containing hybrid tables?
Standard-table zero-copy behavior does not apply to hybrid-table data. Snowflake documents that hybrid tables cannot be cloned at schema or table level. A database clone may include hybrid tables under the documented rules, but their data is physically copied into row store. Snowflake characterizes this as a size-of-data operation, so time and cost can scale with the hybrid data volume.
| Consideration | Standard table, schema, or database clone | Database clone containing hybrid tables |
|---|---|---|
| Data handling | Standard table data initially shares micro-partitions. | Hybrid-table data is physically copied into row store. |
| Storage and cost | Initial sharing; subsequent changes and retained bytes may affect storage. | Physical storage and clone work can scale with data size. |
| Scope and behavior | Review object-specific grants, streams, tasks, and retention. | Hybrid tables cannot be cloned at schema or table level; database-level rules apply. |
| Documented availability | See Snowflake’s general clone reference. | Snowflake’s hybrid-table clone guidance lists AWS and Microsoft Azure commercial regions. |
Because regional availability can change, consult Snowflake’s current hybrid-table cloning documentation before planning a deployment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When is zero-copy cloning a good fit?
- Development and testing: Create a separate working object from existing data without initially duplicating all standard-table micro-partitions. Account for storage as the clone and source diverge.
- Historical recovery or investigation: Clone a supported object at an available Time Travel point when the needed data history has not expired. This is not a substitute for checking retention and operational metadata.
- Environment duplication: Clone a database or schema when you need a broader set of objects, but plan separately for grants, streams, tasks, alerts, and any hybrid tables.
For a clone-based workflow, first choose the object scope and (if needed) historical point; then verify retention and permissions; create the clone; validate its grants and operational objects before use; and monitor storage as changes accumulate.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Free tools Windows power users keep installed
One-click scans. No signup required.
