I'm trying to understand the underlying architecture of Zero-Copy Cloning. If I clone a 50TB production database into a Dev environment, am I charged for an additional 50TB of storage? Also, if the production data changes after the clone is created, how does Snowflake ensure that the Dev environment remains a point-in-time snapshot without affecting the live data?
3 answers
Zero-copy cloning is incredibly efficient because it only clones the metadata, not the actual data files. When you clone that 50TB database, your initial storage cost for the clone is $0. Both the original and the clone point to the same underlying micro-partitions. As soon as you change data in either the Prod or Dev version, Snowflake creates new micro-partitions for those specific changes. You are only billed for the "unique" data that exists in each version. This makes it a perfect tool for testing and rapid environment staging.
Zero-copy cloning is incredibly efficient because it only clones the metadata, not the actual data files. When you clone that 50TB database, your initial storage cost for the clone is $0. Both the original and the clone point to the same underlying micro-partitions. As soon as you change data in either the Prod or Dev version, Snowflake creates new micro-partitions for those specific changes. You are only billed for the "unique" data that exists in each version. This makes it a perfect tool for testing and rapid environment staging.
It’s a game changer for QA. We can spin up a full copy of Prod, run destructive tests, and then just drop the clone without ever risking the live data or doubling our bill.
Agreed! It has completely replaced our old, slow backup-and-restore process for refreshing our development sandbox.
Does this mean that if I drop the original table, the clone will still function perfectly, or is it dependent on those original micro-partitions existing?