Firebolt’s zero-copy clone

Imagine you’re managing a massive production table and need to test some changes or run experiments on the data. What’s your first thought? Copying the entire table might seem like the obvious solution—but it’s slow, expensive, and inefficient, especially if you need to do it repeatedly.

That’s where Firebolt’s new zero-copy clone feature comes in. This capability lets you create an instant duplicate of your table without the heavy costs or delays of traditional copying.

In this article, we’ll dive into the technical details of zero-copy cloning and the underlying Firebolt’s metadata layer and the design considerations that make it possible.

What is Zero-Copy Cloning?

Zero-copy cloning is a powerful feature that lets you create an exact, metadata-level copy of a table almost instantly, without incurring into additional storage costs. The cloned table is fully independent from its source, allowing you to query, test, and experiment as if it were a separate table, all while sharing the same underlying data.

Think of it like the concept of "copy-on-write": when you create a clone the data itself is not duplicated. Instead, both the original and cloned tables reference the same physical data files in object storage. This approach ensures lightning-fast table creation and eliminates the need for costly data duplication.

Since zero-copy cloning is purely a metadata operation, it’s much more efficient than cloning the actual data —it duplicates only the pointers to the data files, avoiding any heavy lifting typically involved in storage operations.

In Firebolt, cloning a table is as straightforward as running a single command:

CREATE DATABASE ultra_fast_staging;

CREATE TABLE ultra_fast_staging.public.playstats_new
CLONE ultra_fast_gaming.public.playstats

Common Use Cases for Zero-Copy Cloning

Zero-copy cloning is a practical feature with several applications, including:

• Creating Snapshots: Save a copy of a table as it exists at a specific point in time for record-keeping or compliance purposes.
• Maintaining Historical Snapshots: Take periodic snapshots (e.g., daily, monthly, or yearly) to preserve a historical view of your data.
• Backup and Recovery: Create a backup of production data before making changes, allowing for quick restoration if needed.
• Testing and Staging: Set up testing or staging environments quickly using cloned data, reducing the time and effort required.

Background on Storing Data and Metadata

Managing metadata in a distributed cloud data warehouse is challenging because multiple independent compute resources can read and write simultaneously. Firebolt’s metadata layer ensures ACID compliance at the Snapshot Isolation level, providing robust transaction guarantees in such an environment.

Firebolt's metadata layer tracks all objects within its object model, including schemas, compute engines, RBAC privileges, and tablets.

A tablet is a collection of rows stored in Firebolt’s indexed, columnar file format on S3. The metadata layer references these S3 objects so the storage layer can efficiently locate and read the appropriate tablets at the right time.

Tablets consist of data-only objects  without any direct association to logical objects like tables, schemas, or databases. It is the responsibility of the metadata layer to map these tablets to their respective tables and track their evolution over  time.

Why Do We Need a Metadata Indirection Layer?

Why can’t we just interact with the objects on S3 directly? Couldn’t we periodically list objects in a bucket to determine what data belongs to a table?

This approach introduces significant challenges:

1. Latency: Listing S3 objects is relatively slow, taking tens to hundreds of milliseconds. This delay would impact query performance if applied to every operation.
2. Consistency: Periodic listing would make it difficult to handle concurrent writes. Data modifications by other writers wouldn’t be visible immediately, and ensuring proper conflict resolution between concurrent writers would become increasingly complex.

The metadata indirection layer addresses these issues by efficiently managing collections of objects like tablets. It ensures low latency and supports multi-writer consistency, enabling Firebolt to maintain performance and reliability.

Additionally, this metadata architecture supports advanced data warehouse features, such as table cloning, which we will explore further in this post.

Tablets metadata

Tables in Firebolt are composed of multiple tablets—potentially tens of thousands. Each tablet is represented in metadata by an identifier and an address, which serves as a pointer to its corresponding objects on S3.

This tablet metadata is lightweight, while tablets on S3 can be as large as 20 gigabytes, the tablet metadata in Firebolt is only about 100 bytes.
This makes metadata operations to be executed very quickly. This efficiency is a fundamental aspect of Firebolt’s metadata layer: working with compact metadata handles is significantly faster and more efficient than directly handling huge S3 objects.

Before zero-copy cloning, Firebolt maintained a strict one-to-one mapping between metadata handles and data objects on S3. With the introduction of zero-copy cloning, this mapping has been relaxed, allowing multiple metadata handles to reference the same S3 data objects.

What Happens During a Clone Operation?

When a clone operation is executed, a new metadata entry is created that points to the same tablets as the original source. This means that the physical data itself is not duplicated. The tablet doesn’t contain any information about its table or database, so by duplicating only the table metadata, we effectively store the same logical reference multiple times.

Since the actual tablet is shared between the tables, the underlying data isn't replicated, only the metadata is.

As noted earlier, metadata is much lighter than the actual data. This makes copying tablet metadata far more efficient and lightweight than copying the physical data itself.

Tables are independent after cloning

After a table is cloned, the original and the clone evolve independently. Any changes, such as updates, inserts, or deletes, to one table do not impact the other. This ensures that each table maintains its own state, even for the data that was initially shared.

When new data is inserted into either table, a new tablet is created in S3 along with a corresponding metadata entry. This metadata entry is exclusively associated with the table where the insert operation was performed.

For deletes or updates, directly modifying the shared tablet would impact other tables that reference it. To prevent this, tablets are designed to be immutable. This also plays nicely with S3 which doesn’t allow in-place modification of objects. Instead, Firebolt maintains a change log for each tablet. This log allows each table's metadata to reference a different unique deletion log, ensuring that every table preserves its own distinct state, even when sharing the same underlying tablet.

‍

Cross-Database Clone

Tablet data files are not tied to specific logical objects like tables or databases. This allows the references of a tablet to be copied from one database to another, while the metadata still points to the same shared storage.

Zero-copy cloning is Firebolt's first cross-database operation, enabling data transfer across databases without the need for exporting and re-importing. Cross-database cloning also simplifies setting up dedicated databases for testing or staging environments, which we plan to support in an even simpler way through a CLONE DATABASE command.

Implementing cross-database cloning is significantly simpler than supporting full cross-database queries, as it involves only metadata operations without the complexities of query planning.

When to Delete Objects on S3?

When two tables reference the same tablet in storage, what happens if one table is dropped? Rest assured, your data is safe.

Tablets in storage are not immediately deleted when a table is dropped or data is removed. Instead, they are retained for future cleanup by the storage garbage collector.

For zero-copy cloning, while data isn’t kept indefinitely, the garbage collector periodically checks for active metadata references against the S3 storage. Any tablet referenced even once is preserved, preventing accidental deletions.

In summary, dropping a table does not trigger storage cleanup that could affect another active clone of the same data.

Performance

We already covered that Zero-copy cloning is extremely fast because only table metadata is copied. The operation's complexity depends not on the table's size but on the number of tablets it contains at the time of cloning.

For perspective, tables can consist of thousands to tens of thousands of tablets, each with metadata of about 100 bytes. In our FireEdge demo, a 60TB table with ~8,000 tablets generated metadata totaling less than one megabyte.

In our first development version, tablet metadata was written one at a time, requiring multiple round trips to our metadata server. While faster than re-ingesting a table, it wasn’t ideal. The first version of zero-copy cloning we shipped batches metadata writes, significantly improving latency. Though there’s still room for optimization, the current speed allows us to clone huge tables very quickly. In the demo linked above, cloning the 60TB takes about four seconds.

This figure demonstrates that the time required for a clone operation scales linearly with the number of tablets in the table. It also highlights the significant performance improvement achieved by batching metadata writes, reducing the overall cloning time.

Clone Storage Costs

Zero-copy cloning eliminates the need for physical data duplication, allowing tables to share the same underlying storage without consuming additional space. This approach significantly reduces storage costs.

Firebolt's pricing model separates compute and storage costs, meaning multiple tables sharing the same storage directly lowers storage expenses. For instance, as of today, the storage price in the us-east-1 region is $23/TB per month. Cloning a 60TB table instead of re-ingesting it can save approximately $46 per day. Check out Firebolt’s Pricing Calculator

Storage billing and usage details can be monitored through Firebolt’s information_schema views, such as storage_billing, storage_metering_history, and storage_history.

Conclusion

Firebolt's zero-copy clone feature offers a cost-efficient and fast solution for cloning tables or databases without incurring additional storage costs.

This blog explores the technical design of the metadata and storage layers, which form the core infrastructure enabling zero-copy cloning.

Additionally, we discuss performance benchmarks with practical examples and highlight tools designed to enhance visibility into consumption and storage costs.