Snowflake zero-copy cloning creates a database object that initially shares its source’s existing data storage rather than making a full copy. For standard tables, that shared data is stored in micro-partitions. The clone and source can then change independently, so writes and retained data can increase storage use; “zero-copy” describes the initial data handling, not a promise that a clone is always free.
What is Snowflake zero-copy cloning?
It is a way to create a clone of a Snowflake object—commonly a database, schema, or table—without initially duplicating the source’s standard table data. The source and clone share underlying micro-partitions until changes create data that is separately owned. Snowflake’s TABLE_STORAGE_METRICS documentation describes the behavior this way: “Cloned tables share the same underlying storage (at the micro-partition level) until either the original table or cloned table is modified.”
As an Amazon Associate I earn from qualifying purchases.
This is useful when you need a separate working copy for development, testing, or recovery, while avoiding an immediate full copy of standard table data. A clone is still a distinct object with its own lifecycle; sharing the initial data does not make it a permanently synchronized mirror.
Recommended Free Tools
How does a clone affect storage and cost?
At creation, a standard clone references the source’s existing micro-partitions. If either object is modified, Snowflake may create new micro-partitions for the changed data. The source and clone can then own different bytes, and their storage footprints can diverge. Retained data may also continue to affect storage use after changes or deletion at the original table. For the accounting details, see Snowflake’s storage cost guidance and data storage considerations.
#1 Best Overall
Therefore, don’t estimate clone cost by counting clone objects alone. The relevant factors include changed data and bytes retained under the applicable lifecycle and retention rules. Snowflake’s Time Travel and Fail-safe storage guidance explains additional storage considerations for historical and backup data.
Where to investigate storage
TABLE_STORAGE_METRICSprovides table storage metrics, including clone-group and byte-ownership information. It is an investigation tool, not an automatic calculation of every charge attributable to a clone.BACKUP_STORAGE_USAGEis another view Snowflake points administrators to for backup storage usage.
How do you clone a Snowflake table?
The basic SQL pattern is:
CREATE TABLE my_table_clone CLONE my_table;This illustrates the syntax only. Use the appropriate database and schema qualification, permissions, and object-specific options for your environment. Snowflake’s CREATE … CLONE reference documents supported object types and options. The command can create clones of databases, schemas, tables, and selected other schema objects.
Rank #2
Can you clone a database or table to an earlier point in time?
For supported database, schema, and non-temporary table clones, Snowflake’s CREATE … CLONE syntax supports AT or BEFORE to select an available historical point. This depends on the required Time Travel history still being available. A historical clone cannot be created if the object did not exist at the requested point or the necessary history has been purged.
For a database or schema clone, child tables may have different retention windows. If a child table lacks sufficient history, the container clone can fail; Snowflake documents IGNORE TABLES WITH INSUFFICIENT DATA RETENTION for applicable cases where unavailable tables can be skipped. Also, the historical state of data and the timing of inherited metadata are not necessarily identical, so a Time Travel clone should not be treated as a complete historical copy of every aspect of an environment. See Snowflake’s cloning considerations.
What should you check before using a clone?
A successful clone does not necessarily behave like a ready-to-run copy of the source environment. Review these object-specific details before depending on it:
- Privileges: Most clone statements do not copy explicit grants unless the supported
COPY GRANTSoption is used. Container grants also need attention. - 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 begins at clone time.
- Tasks and alerts: Tasks and alerts cloned as part of a database or schema are suspended by default. Decide deliberately whether and when to resume them.
- Retention: Historical cloning relies on the retention available for each relevant object. A child table with a shorter retention period can constrain a historical database or schema clone.
- Long-running clones: DML during a long clone, combined with zero-day retention, can make required data unavailable. Snowflake advises avoiding source DML during the operation where practical or temporarily ensuring retention; restore intended retention settings carefully afterward.
How are hybrid tables different?
Standard-table clone behavior does not apply unchanged to hybrid tables. Snowflake says 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 rather than shared as standard-table micro-partitions. Snowflake characterizes this as a size-of-data operation, so time and cost can scale with hybrid-table data size. Its hybrid-table cloning documentation lists availability in AWS and Microsoft Azure commercial regions.
Rank #4
| 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. |
| Storage and cost behavior | Initial sharing avoids another full copy; later writes and retained bytes may affect storage. | Physical storage and clone work can scale with data size. |
| Scope and operations | Review object-specific privileges, 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. | AWS and Microsoft Azure commercial regions, as listed in Snowflake’s hybrid-table clone guide. |
When is zero-copy cloning a good fit?
Use a standard clone when you need a separate database object for development, testing, or a point-in-time recovery scenario, and want to avoid an immediate full copy of standard table data. Before relying on it, verify that the relevant object types and historical data are supported, and review grants, streams, tasks, and retention. If your database contains hybrid tables, account for their physical-copy behavior rather than assuming the whole database clone is zero-copy.
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.
