Cloning and Time Travel for safe development, testing, and rollback

Time Travel lets you query or clone historical versions of tables, schemas, or databases within a defined retention period, while zero-copy cloning creates instant, metadata-only copies of objects for dev/test environments without duplicating storage. Combining both allows you to spin up realistic development environments from a specific point in time without impacting production data or incurring significant storage costs.

1 · Learn the must-know

• 1CLONE combined with AT/BEFORE (Time Travel) lets you create a database, schema, or table as it existed at a past timestamp, offset, or query ID, ideal for building dev/test environments from historical production states.
• 2Zero-copy cloning only duplicates metadata initially; storage costs are incurred only when the clone or the source diverges (new or changed micro-partitions).
• 3Time Travel retention is 1 day by default (0-90 days on Enterprise+ for permanent objects, max 1 day for Standard edition and transient/temporary objects), and cloning beyond that window is not possible since history no longer exists.
• 4Cloning a database or schema recursively clones all child objects (tables, views, stages, file formats, etc.) at that point in time, but does NOT clone privileges granted directly on the child objects unless you have the necessary privileges yourself.
• 5Cloned objects are fully independent post-creation—DML/DDL on the clone or the source do not affect each other, making clones safe for isolated development or testing.
• 6Dropped tables/schemas/databases still within their Time Travel retention period can be cloned using AT(OFFSET => ...) or BEFORE(TIMESTAMP => ...) referencing the object just before it was dropped, useful for recovering or branching from deleted objects.

2 · Check your understanding