Lab 17 · Domain 5 · You are Priya
Instant Dev copy without waiting for a byte dump. You will clone table / schema / database, prove when storage charges start (divergence), and learn primary vs secondary replication without needing a second production account today.
COPY INTO everything —
hours of load and double the storage bill. Riley asks about DR across regions.
CREATE TABLE … CLONE, schema clone, database clone to ALPINE_RETAIL_DEV,
a divergence UPDATE that starts new storage, and commented replication DDL for exam literacy.
Episode 17 · Clone day
I need a safe Dev playground of Alpine before the demo. How long for a full copy?
Seconds, not hours — if we clone. Snowflake points at the same micro-partitions until someone writes and forces new ones. That’s zero-copy.
Clone ≠ share. Clone is a new object you own; share is live access for another account.
New table/schema/DB that starts sharing storage pointers.
CREATE TABLE T2 CLONE T1;Immediately materializes new micro-partitions — pay storage now, wait for data move.
After clone, shared history is free-ish pointers. When either side writes, new partitions are stored and billed.
Primary DB → secondary in another account/region. Refresh keeps it current. Failover promotes secondary.
Cloning creates a new object. You need privileges to create the target (e.g. CREATE TABLE in the schema) and ownership/select-style rights on the source as required by Snowflake’s clone rules. Grants on the source do not automatically make every role able to clone into a privileged place — think “who can CREATE the new object?”
Before Step 1
If I clone CUSTOMERS, am I protected if someone drops the original tomorrow?
Partially independent object — but Time Travel / Fail-safe on the original is still your recovery story. Clone is for Dev/QA isolation, not a substitute for retention policy.
What this does: Instant CUSTOMERS_CLONE pointing at the same data as LAB.CUSTOMERS.
USE ROLE ROLE_CORE_LAB_ADMIN;
USE WAREHOUSE WH_CORE_XS;
USE DATABASE ALPINE_RETAIL;
USE SCHEMA LAB;
CREATE OR REPLACE TABLE CUSTOMERS_CLONE CLONE CUSTOMERS;
SELECT COUNT(*) AS CLONE_ROWS FROM CUSTOMERS_CLONE;CUSTOMERS — created in secondsWhat this does: Clones the whole LAB schema, then clones the database into ALPINE_RETAIL_DEV.
CREATE OR REPLACE SCHEMA LAB_CLONE CLONE LAB;
CREATE OR REPLACE DATABASE ALPINE_RETAIL_DEV
CLONE ALPINE_RETAIL;LAB_CLONE and ALPINE_RETAIL_DEV exist in the accountBefore Step 3
You said zero-copy. So clones are free forever?
Until someone writes. UPDATE the clone — Snowflake stores new micro-partitions for the changed data. Unchanged history can still be shared. That’s when the bill grows.
What this does: Changes only the clone; original stays intact — independent objects after write.
UPDATE ALPINE_RETAIL.LAB.CUSTOMERS_CLONE
SET FULL_NAME = 'Cloned Name Change'
WHERE CUSTOMER_ID = 1;
SELECT CUSTOMER_ID, FULL_NAME
FROM ALPINE_RETAIL.LAB.CUSTOMERS WHERE CUSTOMER_ID = 1;
SELECT CUSTOMER_ID, FULL_NAME
FROM ALPINE_RETAIL.LAB.CUSTOMERS_CLONE WHERE CUSTOMER_ID = 1;Cloned Name ChangeWhat this does: Shows the exam shape of enabling replication. Needs a second account and often Business Critical for full failover.
-- ALTER DATABASE ALPINE_RETAIL
-- ENABLE REPLICATION TO ACCOUNTS <org>.<account>;
--
-- -- On the secondary account:
-- CREATE DATABASE ALPINE_RETAIL
-- AS REPLICA OF <org>.<primary>.ALPINE_RETAIL;
-- ALTER DATABASE ALPINE_RETAIL REFRESH;Say: Clone creates a new object that initially references the same micro-partitions — no immediate full byte duplication. CTAS/COPY materializes new partitions right away. Storage grows as the clone and source diverge via writes.
Say: You need rights to create the target object (CREATE TABLE/SCHEMA/DATABASE in the destination) and appropriate access to the source. Cloning doesn’t magically bypass RBAC; ownership of the new object follows normal create rules.
Say: Primary is the writable source account/database. Secondary is a replica (typically read-only) refreshed from the primary. Failover promotes a secondary to take writes after an outage/planned cutover.
Say: Many multi-account failover / client-redirect style features require Business Critical (or higher). Don’t claim full HA on Standard. Check current docs, but Core exams expect BC for advanced failover.
Say: At clone time you mostly pay metadata/pointers for shared history. When either side inserts/updates/deletes, Snowflake writes new micro-partitions — those unique bytes are stored and billed. Unchanged shared history can remain shared.
CUSTOMERS_CLONE, LAB_CLONE, and ALPINE_RETAIL_DEV via zero-copy CLONE —
not a BYTE dump. Storage grows after divergence, which I proved with an UPDATE on the clone only.
Replication is a different-account story: enable on primary, create replica, refresh; failover often needs Business Critical.
Outcome: clone vs copy vs replicate sorted for Domain 5.”