A Quick Look At Zero Copy Cloning In Snowflake

[@syedasadkhan]

The use case you went over assumes that the production database has not been updated since clone was created. This would require halt of upstream processes to halt especially those that feed the production database

[@anandperi7060]

Not sure anyone monitors these posts anymore... but if you update every single row in a table with the price change... are you not literally doing a copy of the full table anyways? Assuming the micro partitions are immutable and you need to preserve the changes for time travel etc? Maybe a better example would have helped your cause.

[@TheReallyRealSunTzu]

Zero copy cloning will only create new column with the adjusted price after you promote the changes to the 'orders' table in prod. Snowflake has columnar storage, so there is no need to rewrite all the rows (with all columns) again. The original column with 20% more price will also remain for duration of time travel (upto 90 days) and fail safe period (7 days) but this old column won't be referenced in any new queries after the prod changes are completed. So you only pay additional cost for storing the new column with updated price until the end of time-travel period. After which, you pay the same amount as you did before the changes. That's my understanding

[@aacarr5]

Does this work for non-relational databases? Also, does the copying size max out? eg a 20 tb database?

[@snowflakedevelopers]

Hi Andrew! This will work for databases within Snowflake. For databases, schemas, and tables, a clone does not contribute to the overall data storage for the object until operations are performed on the clone that modify existing data or add new data. For more information, see: docs.snowflake.com/en/sql-reference/sql/create-clone#general-usage-notes