A zero-copy clone creates a new database, schema or table that points at the same micro-partitions as the original, by copying only metadata. It is instant, however big the source is, and it costs no extra storage at the moment you create it.
How it works
CREATE DATABASE analytics_dev CLONE analytics_prod;
A 20 TB database clones in seconds, because Snowflake only copies the pointers to the micro-partitions. Both objects now share the same files. When you change data in the clone, Snowflake writes new micro-partitions for those changes, and the clone alone owns them. The original is untouched. Likewise, changes to the original do not appear in the clone. You pay storage only for the micro-partitions that differ between them.
Common uses
- A dev or test environment with real production-shaped data, created in seconds, and thrown away afterwards. No export and import.
- A safety copy before a risky change, such as a large backfill or a schema migration. If it goes wrong, you can swap the tables back.
- Reproducing a bug. Clone the table, then run the failing logic on the clone.
- Testing a pipeline change on the full data, without touching the real tables.
Combined with Time Travel
You can clone as of a past time:
CREATE TABLE orders_before CLONE orders AT (TIMESTAMP => '2025-03-01 08:00:00'::timestamp);
That is a quick way to recover a table, or to compare today with an earlier state.
Things to watch
- Clones are independent copies for writes, but they keep old micro-partitions alive. If you drop the original, storage for shared files is still charged to the clone, and Time Travel data adds up.
- Grants on the source objects do not always carry over as you expect (child objects keep theirs, the cloned container does not copy its own grants), so check privileges on the clone.
- Clones of tables with streams or pipes have special rules, so check the docs.
The core point for interviews: it is metadata-only, so it is fast and cheap, and storage grows only with the differences.