Rana Nasri Ghazzi

Table Cloning in Databricks: Deep Clone vs. Shallow Clone

If you’ve worked with Delta Lake tables in Databricks, you’ve probably needed a copy of a table at some point — for testing, backups, or migrating data. Databricks makes this easy with the CLONE command, which comes in two flavors: deep clone and shallow clone. Understanding the difference can save you time, storage costs, and headaches.

Deep Clone: The Full Copy

A deep clone creates a complete, independent copy of a table — both its metadata and its underlying data files. Once the clone finishes, it has no dependency on the source table whatsoever.

CREATE TABLE target_table
DEEP CLONE source_table;

This is the right choice when you need durability and independence: backing up a table before a risky operation, archiving data long-term, or migrating a table to another workspace or region.

The tradeoff is cost — copying every data file takes time and doubles your storage footprint. The good news is that deep clones are incremental: re-running the same clone command later only copies files that changed since the last clone.

Shallow Clone: The Fast, Lightweight Copy

A shallow clone copies only the table’s metadata and transaction log — not the actual data files. The new table simply points back at the source’s existing Parquet files.

CREATE TABLE target_table
SHALLOW CLONE source_table;

This makes shallow clones nearly instantaneous and essentially free in storage terms. They’re perfect for short-lived use cases: spinning up a dev or test environment from production data, experimenting with a schema change, or reproducing a bug without touching the real table.

The catch is that a shallow clone isn’t fully independent — if the source table’s underlying files get deleted or vacuumed, the clone can break.

Time Travel and Clones

Both clone types support Delta Lake’s time travel, so you can clone a table as it existed at a specific version or timestamp:

CREATE TABLE target_table
DEEP CLONE source_table VERSION AS OF 12;

CREATE TABLE target_table
SHALLOW CLONE source_table TIMESTAMP AS OF '2026-09-01';

This is especially useful for debugging — you can recreate the exact state of a table at the moment an issue occurred.

Choosing the Right Clone

A Few Gotchas

• Shallow clones don’t automatically carry over CDC metadata (like _change_data).
• Permissions and grants on the source table are not inherited by the clone — you need to set them explicitly on the target.
• CREATE OR REPLACE TABLE … CLONE … lets you refresh an existing clone instead of recreating it from scratch.

Cloning is a small feature, but it’s one of those tools that quietly makes working with large-scale data pipelines much safer and faster. Whether you need a quick sandbox or a durable backup, Databricks gives you the right tool for the job.