Clone use cases (dev, testing, backups) in Snowflake - Step-by-Step Execution

Process Flow - Clone use cases (dev, testing, backups)

Original Database/Table

↓

Create Clone

↓

Clone is Independent

↓

Use Clone for Dev/Testing/Backup

↓

Changes in Clone do NOT affect Original

↓

Optionally Refresh or Drop Clone

Start with an original database or table, create a clone that is independent, then use it safely for development, testing, or backups without affecting the original.

Execution Sample

Snowflake

CREATE DATABASE prod_db;
CREATE DATABASE dev_db CLONE prod_db;
-- Use dev_db for testing
DROP DATABASE dev_db;

Create a production database, clone it for development, then drop the clone after testing.

Process Table

Step	Action	Object State	Result
1	CREATE DATABASE prod_db	prod_db created	Empty database ready for data
2	CREATE DATABASE dev_db CLONE prod_db	prod_db unchanged, dev_db clone created	dev_db is a snapshot clone of prod_db
3	Insert test data into dev_db	prod_db unchanged, dev_db modified	Changes only in dev_db, prod_db safe
4	Run tests on dev_db	prod_db unchanged, dev_db modified	Testing isolated from prod_db
5	DROP DATABASE dev_db	prod_db unchanged, dev_db removed	Clone removed, prod_db intact

💡 Clone dropped after testing, original database remains unchanged

Status Tracker

Object	Initial	After Clone	After Test Data Insert	After Drop Clone
prod_db	Not exist	Exists (original)	Exists (original)	Exists (original)
dev_db	Not exist	Exists (clone of prod_db)	Exists (clone with test data)	Not exist

Key Moments - 3 Insights

Does modifying the clone affect the original database?

No, as shown in steps 3 and 4 of the execution_table, changes in the clone (dev_db) do not affect the original (prod_db).

Can the clone be used for backup purposes?

Yes, because the clone is a snapshot of the original at creation time, it can serve as a backup without impacting the original data.

What happens when the clone is dropped?

Dropping the clone removes only the clone (dev_db) and leaves the original (prod_db) unchanged, as shown in step 5.

Visual Quiz - 3 Questions

Look at the execution_table, what is the state of prod_db after step 3?

A prod_db has test data inserted

B prod_db remains unchanged

C prod_db is dropped

D prod_db is cloned again

💡 Hint

Refer to the 'Object State' column in step 3 of the execution_table

At which step is the clone dev_db removed?

A Step 5

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'Action' column for when DROP DATABASE dev_db occurs

If you insert data into the clone, what happens to the original database?

A Original database also gets the data

B Original database is deleted

C Original database remains unchanged

D Original database is renamed

💡 Hint

See steps 3 and 4 in the execution_table for how changes affect prod_db

Concept Snapshot

Snowflake clones create independent copies of databases or tables.
Clones share storage initially but changes are isolated.
Use clones for development, testing, or backups safely.
Dropping a clone does not affect the original.
Cloning is fast and storage-efficient.

Full Transcript

This visual execution shows how Snowflake clones work. First, an original database is created. Then a clone is made, which is an independent snapshot. You can insert test data and run tests on the clone without changing the original. Finally, the clone can be dropped safely. This process supports development, testing, and backup use cases by isolating changes and preserving the original data.