TL;DR
Snowflake’s CLONE command creates an instant, fully independent copy of a table, schema, or database without physically copying any data. It works by pointing the new object at the same underlying storage as the source, so even a 10TB clone costs nothing extra at first. Storage cost only appears once someone writes to either the clone or the source, because that’s when the two copies start to diverge. A clone does not inherit everything from its source, and that’s where most migration surprises happen. Container-level privileges don’t carry over, streams lose access to any records they hadn’t consumed yet, and tasks come back suspended. None of that triggers an error message, so it’s easy to miss until something breaks downstream. Because Snowflake can’t change a table’s persistence type in place, the standard pattern for schema changes is to clone it, validate it, then swap it in.
Key Takeaways
CREATE TABLE ... CLONE, CREATE SCHEMA ... CLONE, and CREATE DATABASE ... CLONE all copy structure and data as a zero-copy operation; no physical data moves until one side diverges.A cloned database or schema does NOT inherit privileges granted on the container itself, only child-object privileges carry over, and only when you clone the container. Streams lose access to unconsumed records at clone time, and tasks come back suspended, both silently, with no error to flag it. Storage costs stay at zero only until DML touches either the source or the clone; after that, Snowflake bills the diverged micro-partitions independently on both sides. Snowflake can’t change a table’s persistence type in place, so the standard pattern for schema changes is clone, validate, then ALTER TABLE ... SWAP WITH. BigQuery has a similar table-clone primitive, but Snowflake’s version works at table, schema, and database scope with no regional lock, which neither BigQuery, Redshift, nor Microsoft Fabric fully match. How Do You Test a Schema Migration Against Real Production Data Without Touching Production? A data engineer needs to validate a column-type change before it ships. The safe option, a sanitized subset, misses the null patterns and skew that live in the real table. The other option, restoring a backup, takes long enough that the change sits in a PR overnight.
Snowflake’s answer to that specific problem is the clone: a full, independent, point-in-time copy of a table, schema, or database that exists in seconds and costs nothing until someone writes to it. This guide focuses specifically on the CLONE mechanics; for the broader syntax of standard, transient, and temporary tables, see our Snowflake CREATE TABLE guide . Most teams learn the clone syntax in a single afternoon. What takes longer to learn is which parts of the source object the clone quietly leaves behind.
What CREATE TABLE … CLONE Actually Does The command looks almost too simple for what it does, and Snowflake’s own CREATE … CLONE reference covers the full syntax across every cloneable object type:
CREATE TABLE orders_dev CLONE orders;
CREATE SCHEMA staging_dev CLONE staging;
CREATE DATABASE analytics_dev CLONE analytics;Each statement produces a new, independent object. Snowflake doesn’t copy a single byte of the underlying data. Instead, the clone’s metadata points at the exact same micro-partitions the source already owns. Both objects can be queried immediately, and both return identical results, because at the instant of cloning they are the same physical data.
Copy-on-Write: Why Zero-Copy Isn’t Zero-Cost Forever The mechanism underneath is copy-on-write. As long as nobody touches either the source or the clone, they keep sharing the same micro-partitions, and Snowflake bills for that storage exactly once.
The moment a DML statement modifies rows on either side, Snowflake writes new micro-partitions for the changed data and leaves the untouched partitions shared. From that point forward, the two objects are billed for whatever has diverged, not for the full table. A clone that never gets written to can sit at zero incremental storage cost indefinitely; a clone that takes a full nightly reload starts accumulating its own storage bill within a day.
What a Clone Shares With Its Source at Creation Time A clone inherits the source object’s metadata as it existed at the moment the CREATE ... CLONE statement ran: column definitions, comments, and clustering key definitions all carry over. What it does not inherit is any state tied to execution, like a paused task or a stream’s read position, because those describe what’s happening to the object, not what the object is .
Cloning Scope: Table vs Schema vs Database The CLONE keyword works at three different scopes, and the scope changes what gets pulled in.
Scope What Gets Cloned Typical Use Table-level One table: its data, clustering key, and column-level settings Testing a single schema change against real production data Schema-level Every table, view, stream, task, sequence, file format, and stage inside the schema Standing up one feature-branch or PR-scoped environment Database-level Every schema in the database and everything inside each one Full-environment migration rehearsals
Table-Level Clone A table clone is the narrowest scope: one object, its data, its clustering key, and its column-level settings. Nothing about the surrounding schema is touched.
Schema-Level Clone Cloning a schema recursively clones every table, view, stream, task, sequence, file format, and stage inside it, with each child object following its own cloning rules. This is where the exceptions listed later in this guide, streams, tasks, pipes, start to matter, because a schema clone can silently leave several of those child objects in a different state than their source.
Database-Level Clone A database clone recurses one level further, cloning every schema and everything inside each one. This is the fastest way to stand up a full parallel environment, and it’s also the scope where unnoticed gaps (a suspended task three schemas deep, for instance) are easiest to miss.
What Never Gets Cloned Regardless of scope, a few things never carry over. Ownership privileges on the database or schema container itself don’t transfer to the clone. Pipes that reference internal (Snowflake-managed) stages aren’t cloned. Data files sitting in a table’s internal stage aren’t copied. And an object clone always reflects the source’s state at the moment the statement runs, so any Time Travel clause you attach only changes which point in the past gets frozen, not which categories of metadata are included.
Watch on YouTube
Snowflake vs Redshift: Choosing the Right Data Warehouse Platform
A Kanerika platform-choice walkthrough covering the same kind of architectural tradeoff this guide applies at the clone level.
Clone Plus Time Travel: Point-in-Time Clones Adding an AT or BEFORE clause lets a clone reach back to a specific moment instead of the current state:
CREATE TABLE orders_snapshot CLONE orders
AT (TIMESTAMP => '2026-08-01 00:00:00'::TIMESTAMP);
CREATE TABLE orders_restore CLONE orders
AT (OFFSET => -3600);
CREATE TABLE orders_debug CLONE orders
AT (STATEMENT => '01b3c4d5-0000-1234-0000-abcd12340000');TIMESTAMP takes an explicit date and time (cast to the TIMESTAMP type). OFFSET takes a negative number of seconds relative to now, which is the fastest way to say “as of an hour ago.” STATEMENT takes a query ID from the last 14 days, useful for reconstructing exactly what a specific job saw. For the retention windows and recovery mechanics behind all three parameters, see our deeper look at Snowflake Time Travel .
Recovering Yesterday’s Table Without Restoring Over Production Because the clone is a new, independent object, pulling a point-in-time copy never touches the live table. That’s the practical advantage over a restore: instead of overwriting production to inspect a prior state, a team clones the prior state alongside production, compares the two, and drops the clone when they’re done.
Why This Fails: Retention and Purge Gotchas A Time Travel clone can only reach as far back as the source’s DATA_RETENTION_TIME_IN_DAYS allows. Ask for a timestamp older than that window, or older than when the table was created, and the statement fails outright. Schema and database clones add a related trap: if any child table’s retention has already purged the requested point in time, the whole clone fails, unless the statement explicitly adds IGNORE TABLES WITH INSUFFICIENT DATA RETENTION to skip those tables instead of aborting.
Checklist
Snowflake Performance Optimization Checklist
A practical checklist for keeping Snowflake environments, including clone-heavy dev and test setups, performant and cost-controlled.
Get the Checklist → Permissions and Grants: the Rule That Catches Migrating Teams This is the single most common surprise for teams coming from a database that treats a copy as inheriting everything the original had.
Why a Cloned Database or Schema Doesn’t Inherit Container Privileges When a database or schema is cloned, the child objects inside it keep their existing privilege grants. The container itself does not: whatever roles had access to the source database or schema, that access is not automatically extended to the clone. Whoever runs the clone becomes the owner of the new container and has to grant access explicitly.
COPY GRANTS on Table and View Clones Table and view clones behave differently, and the behavior depends on one keyword. Add COPY GRANTS to a CREATE TABLE ... CLONE or CREATE VIEW ... CLONE statement, and every explicit privilege on the source (except ownership) copies over to the new object. Leave it off, and the clone starts with no explicit grants but does pick up whatever default future-grants are configured on the schema. Teams that assume grants always follow the object end up with a dev clone nobody but the creator can query.
Who Owns a Cloned Pipe Pipe ownership is its own case: the role that runs the CREATE ... CLONE statement becomes the owner of the cloned pipe, not the role that owned the source pipe. Combined with the fact that pipes referencing internal stages aren’t cloned at all, pipe behavior is worth checking explicitly any time a clone includes ingestion objects.
What Breaks Silently When You Clone None of the following are guesses; they’re documented in Snowflake’s own cloning considerations reference , which lists what carries over and what doesn’t across every object type. None of the behaviors below throw an error. They just quietly leave the clone in a different operational state than the source, which is exactly what makes them easy to miss in a migration runbook.
Streams: Unconsumed Records Become Inaccessible A stream tracks changes to a table since it was last consumed. Clone the table (or the schema containing it), and any records the stream hadn’t yet processed become inaccessible in the clone. The cloned stream’s change-tracking history effectively restarts at clone time, so a pipeline built on “the stream always has everything since the last consume” needs a reconciliation step after any clone.
Tasks: Suspended by Default Every task inside a cloned schema or database comes back suspended, regardless of whether the source task was running. This is deliberate, Snowflake won’t silently start firing a scheduled job in a brand-new environment, but it means a clone of a production schema does not reproduce production’s automation until someone manually resumes each task with ALTER TASK ... RESUME.
Sequences and Foreign Keys: Reference the Source Unless Cloned Together A table with a default value pulled from a sequence keeps pointing at the original sequence after cloning, unless both the table and the sequence were cloned together in the same schema or database operation. Left unchanged, every insert into the clone advances the same sequence the production table uses, which can produce duplicate or skipped values depending on how the two objects are used afterward. The fix is an explicit ALTER TABLE ... ALTER COLUMN ... SET DEFAULT .nextval once the clone exists. Foreign keys follow the identical rule: a cloned table only references its cloned parent table if both were cloned together in the same operation; otherwise it keeps pointing at the source’s parent table.
Kanerika Service
Snowflake Consulting and Implementation
Kanerika is a Snowflake Select Tier Partner that designs, migrates, and operates Snowflake environments end to end, including clone-based testing and governance.
Explore Snowflake Services Clustering, Search Optimization, External Tables, and Iceberg Tables A clone inherits its source’s clustering key definition, but Automatic Clustering itself comes back suspended and has to be resumed manually with ALTER TABLE ... RESUME RECLUSTER. Search Optimization’s access path clones as zero-copy too, but can accrue its own maintenance cost if it falls out of date. External tables clone individually without touching the underlying cloud storage they reference; see our guide to Snowflake external tables for how that storage layer works. Iceberg tables clone with genuinely distinct metadata (a new table UUID and sequence numbers), and Snowflake enforces that the source and clone match on transience, a transient Iceberg table can’t be cloned into a permanent one, or the reverse.
Storage Billing After Divergence: Where the Silent Cost Comes From The zero-copy promise is real at the moment of creation. What it doesn’t promise is that the clone stays free forever, and the gap between those two facts is where clone-related storage bills sneak up on teams.
How Copy-on-Write Billing Actually Works Every write to either the source or the clone generates new micro-partitions for just the changed data. Those new partitions are billed independently; the untouched partitions keep being shared and stay billed once. A clone that gets a single nightly load accumulates its own storage footprint one day’s worth of changes at a time, and that footprint never merges back.
Watch on YouTube
Snowflake to Microsoft Fabric Migration: Real Cost Breakdown (2026)
A line-by-line breakdown of what a Snowflake-to-Fabric migration actually costs, the same kind of divergence and storage math that turns a free clone into a real line item over time.
Clone Sprawl: the Pattern That Inflates Storage Bills The actual cost driver is rarely one clone, it’s the accumulation of many. A team that clones a multi-terabyte production database before every migration, every schema test, and every one-off investigation, and never drops the ones it’s done with, ends up paying full storage for a dozen forgotten diverged copies. Because the initial clone is free, there’s no natural moment that forces cleanup the way an expensive backup restore would.
Retention Settings That Cap the Cost Two settings keep clone sprawl in check. Setting DATA_RETENTION_TIME_IN_DAYS = 0 on throwaway clones removes their Time Travel storage overhead immediately once they’re dropped. Using transient tables (or transient schemas/databases) for short-lived clones goes further, skipping Fail-safe entirely, which is the 7-day recovery window that costs storage whether or not anyone ever needs it. Neither setting is the default, so both have to be a deliberate part of the clone workflow, not an afterthought.
Dev, Test, and Branching Workflows Built on Clone Once the mechanics and the gotchas are accounted for, clone becomes a genuinely useful operating primitive, not just a one-off recovery tool.
Clone-Before-You-Touch-It as an Instant Rollback Point Before any change that’s hard to reverse, a schema migration, a bulk update, a permission overhaul, cloning the affected object first creates a rollback point with no upfront storage cost. If the change goes wrong, the clone is the known-good state to compare against or fail back to; if it goes fine, the clone gets dropped and never cost more than the day or two of divergence it accumulated.
Feature-Branch Environments and CI/CD Pull-Request Clones Teams running dbt or a similar transformation layer increasingly wire clone directly into CI: every pull request triggers a clone of the target schema or database, the PR’s changes run against that clone, and the tests execute there instead of against a shared, sanitized test dataset. Because the clone reflects production’s actual data distribution, tests catch edge cases that a hand-built fixture table would miss. Each clone is disposable, scoped to one PR, and dropped once the PR merges or closes.
Transient Clones to Skip Fail-Safe Charges For any clone that exists for hours or days rather than as a long-lived environment, creating it as transient (or cloning into a transient schema) removes the Fail-safe cost entirely. Fail-safe exists to protect against catastrophic data loss on permanent objects; a disposable PR-scoped clone doesn’t need that protection, and paying for it anyway is pure waste.
The Swap-With-Clone Pattern for Schema Changes Snowflake doesn’t allow changing a table’s persistence type (standard, transient, temporary) in place. Once a table is standard, it stays standard until it’s recreated.
Why You Can’t Change Persistence Type in Place This isn’t an oversight, persistence type determines how Snowflake allocates storage, Time Travel, and Fail-safe for the object from the moment it’s created, and those aren’t attributes that can be flipped on an existing set of micro-partitions without effectively rebuilding the object. A temporary table is bound by the same rule, it can’t be converted to standard or transient in place either, only cloned and swapped like any other persistence change.
Clone, Validate, Swap, Drop The standard workaround is a four-step pattern: clone the table into the new persistence type or with the new schema change applied, validate row counts and query results against the original, use ALTER TABLE SWAP WITH to atomically exchange the two objects’ names and contents, then drop what is now the old table. The swap is instantaneous and applies to the table as a whole, so downstream views and queries referencing the original table name never see a gap. This is a different operation from a plain table rename , which changes one object’s name without exchanging contents with another.
Case Study
Real-Time Insights Across Distributed Operations via Snowflake Migration
Kanerika replaced manual reconciliation across regional systems with governed, centralized Snowflake data, using disciplined table-type and clone-based testing strategy.
Read the Case Study → Snowflake Clone vs BigQuery, Redshift, and Microsoft Fabric Zero-copy cloning is one of the more genuinely differentiated features in Snowflake’s architecture, but “genuinely differentiated” isn’t the same as “unique to Snowflake.” It’s worth being precise about what the alternatives actually offer.
Platform Zero-Copy Clone Statement What It’s Called Snowflake CREATE TABLE/SCHEMA/DATABASE ... CLONEClone BigQuery (GCP) CREATE TABLE ... CLONETable clone Microsoft Fabric (Azure) CREATE TABLE AS CLONE OFZero-copy clone Redshift (AWS) No zero-copy statement, snapshot-and-restore instead Snapshot / restore Databricks SHALLOW CLONEShallow clone
BigQuery’s Table Clones: a Real Equivalent, With a Regional Catch BigQuery has its own table clone feature that works the same way at the mechanical level: a lightweight reference to the source data with storage billed only for what diverges. The meaningful difference is scope and geography. BigQuery’s clone destination has to sit in the same region as the source table, and BigQuery’s cloning primitive is table-scoped, with database/project-level cloning handled differently. Snowflake’s clone works identically at table, schema, and database scope with no regional constraint attached.
Microsoft Fabric Warehouse Has Zero-Copy Clone Too, Scoped to One Table Fabric Warehouse added its own zero-copy primitive, CREATE TABLE AS CLONE OFhow Fabric table clones work in detail. The gap versus Snowflake is scope and depth: Fabric’s clone is table-only (no schema- or database-level clone in one statement), and its point-in-time window is a fixed 7 days against Snowflake’s configurable up to 90 for standard tables.
Why Redshift Still Doesn’t Have a True Zero-Copy Clone Primitive Redshift’s closest equivalent is snapshot-and-restore: a full backup mechanism that’s built for disaster recovery, not for spinning up a disposable dev copy in seconds. It works, but it isn’t zero-copy, and it isn’t fast enough to use as a CI/CD primitive the way a Snowflake, BigQuery, or Fabric clone can be.
Databricks’ Shallow Clone: Built to Be Short-Lived Databricks’ Delta Lake includes a shallow clone that shares the same copy-on-write logic. The practical difference is intent: shallow clones are generally treated as short-lived references tied to the source table’s transaction log, rather than the fully independent, long-term object a Snowflake clone becomes the instant it’s created.
Common Clone Mistakes to Avoid Every mistake below traces back to one of the gotchas already covered in this guide, privileges that do not inherit, tasks that come back suspended, storage that quietly diverges, but they are worth listing on their own because they are the ones that actually show up in a migration runbook or a PR review. Skim this list before signing off on any clone-based cutover:
Assuming a cloned database or schema inherits the container’s privileges, then wondering why nobody but the creator can query it. Forgetting that tasks come back suspended, and finding out a “cloned” production schedule silently never ran. Cloning a table without its sequence and leaving inserts pointed at the original sequence, corrupting ID generation on one side or the other. Leaving diverged, forgotten clones around indefinitely instead of setting a short retention period or dropping them once a PR or investigation closes. Treating every clone as permanent instead of transient, and paying for Fail-safe on objects that exist for a single afternoon. Requesting a Time Travel clone further back than the source’s retention window allows, and treating the resulting error as a bug instead of a retention setting to check first. How Kanerika Approaches Clone-Based Environments in Snowflake Migrations Kanerika is a Snowflake Select Tier Services Partner, and clone strategy comes up in nearly every Snowflake migration and modernization engagement, usually the moment a client asks how to test a cutover without risking the production warehouse.
The approach starts with an audit of what actually needs cloning and at what scope: a single staging table for a targeted schema test doesn’t need a full database clone, and a full-environment migration rehearsal usually does. From there, Kanerika’s teams set explicit retention and transience policies on every clone created for migration testing, rather than letting them default to standard/permanent, specifically to avoid the storage sprawl pattern described above.
In one Snowflake migration engagement, involving a client running analytics across distributed operations, Kanerika’s table-type and refresh-strategy redesign, including a disciplined clone-based testing approach for schema changes, contributed to a 60% reduction in manual reconciliation effort.
The pitfalls Kanerika’s teams watch for on every engagement mirror the mistakes list above: unverified task state after a schema clone, sequence references left pointed at production, and clones left running past the point they were actually needed. Catching those before go-live is usually the difference between a clean migration and a Monday-morning surprise.
Talk to Kanerika
Planning a Snowflake Migration or Modernization?
Kanerika scopes clone-based testing, governance, and cost controls into every Snowflake engagement from day one.
Schedule a Demo → Frequently Asked Questions
Does cloning a Snowflake table cost anything? Not at the moment of creation. A clone starts by referencing the same micro-partitions as the source, so there is no additional storage cost until either the source or the clone is modified. Once DML touches either side, Snowflake writes new micro-partitions for the changed data and bills that storage independently, so a clone that is never written to can stay at zero incremental cost indefinitely.
Can I clone a Snowflake table into a different database or schema than the source? Yes. The clone’s target can be in any database or schema you have privileges to create objects in; it does not have to match the source’s location. This is common when standing up a dev or test environment in a separate database while cloning from a production schema.
Why can't my team query a database I just cloned? Because a cloned database or schema does not inherit the privileges granted on the container itself, only the privileges on child objects inside it carry over, and only when those objects are cloned together with the container. Whoever runs the CLONE statement becomes the owner of the new container and has to grant access to it explicitly, the same as creating a brand-new database.
Do tasks and streams keep running after I clone a schema? No. Every task inside a cloned schema or database comes back suspended by default, regardless of whether the source task was running, and has to be resumed manually with ALTER TASK … RESUME. Streams lose access to any records that were unconsumed at the moment of cloning, so a pipeline that depends on the stream having everything since the last consume needs a reconciliation step after any clone.
How far back can a Snowflake Time Travel clone reach? Only as far back as the source object’s DATA_RETENTION_TIME_IN_DAYS setting allows, and never further back than when the table was created. Requesting a timestamp outside that window makes the CLONE statement fail. For schema or database clones, the whole operation fails if any child table’s Time Travel data has already been purged for the requested point, unless the statement explicitly adds IGNORE TABLES WITH INSUFFICIENT DATA RETENTION to skip those tables instead.
Can I clone a temporary table in Snowflake? A temporary table only exists for the session that created it, so there is nothing to clone once that session ends, and another session cannot see or reference it to begin with. Standard and transient tables are the ones typically cloned for dev, test, or point-in-time recovery use cases.
If I update the source table after cloning it, does the clone see the change? No. A clone is a fully independent object from the moment it is created. Changes made to the source afterward, inserts, updates, deletes, are not reflected in the clone, and changes made to the clone are not reflected back in the source. Each side only accumulates its own new micro-partitions as it diverges.
What's the safest way to change a Snowflake table's persistence type? Snowflake doesn’t allow changing a table’s persistence type, standard, transient, or temporary, in place. The standard pattern is to clone the table into the new persistence type, validate row counts and query results against the original, use ALTER TABLE original SWAP WITH clone to atomically exchange the two objects, then drop what is now the old table. The swap is instantaneous, so downstream views and queries never see a gap.
