---
title: Storage Lifecycle and Management
sidebar_position: 3
description: Understand how MotherDuck manages data storage across different lifecycle stages and how this affects your billing and data management strategies.
---

Understanding MotherDuck's storage lifecycle is crucial for optimizing costs and managing data effectively. Unlike traditional databases where deleted data is immediately freed, MotherDuck implements a sophisticated multi-stage storage system that ensures data safety while providing cost transparency. This system is particularly important for organizations that share data, use zero-copy cloning, or need to understand their storage footprint for billing purposes.

## Storage lifecycle overview

The following documents MotherDuck's storage lifecycle.

```mermaid
graph LR;
    A[Active Bytes]-->|bytes deleted or updated|B[Historical Bytes];
    B-->|shares dropped|C[Retained for Clone Bytes];
    B-->|historical retention period passes, or snapshots become unnamed|D[Failsafe Bytes];
    C-->|bytes deleted or updated by cloned databases|D[Failsafe Bytes];
    D-->|7 day retention|E[Deleted];
```

There are 5 distinct stages of the storage lifecycle:

1. **Active bytes**: Actively referenced bytes of the database. These bytes are accessible by directly querying the database
2. **Historical bytes**: Non-active bytes referenced by a historical [snapshots](/concepts/snapshots) or share of this database
3. **Retained for clone bytes**: Bytes referenced by other databases (through zero-copy clone) that are no longer referenced by this database as active or historical bytes  
4. **Failsafe bytes**: Bytes that are no longer referenced by any database or share that are retained for some period of time as system backups
5. **Deleted**: Bytes are fully removed from the system and no longer accessible

MotherDuck will run a periodic job that will reclassify data to the proper storage lifecycle stage.

Data can only flow through the storage lifecycle unidirectionally, from left to right.

The following conditions can trigger data to be reclassified to a new stage:

| Trigger | State Transition |
|---------|------------------|
| Data is deleted or updated in the database | Active → Historical |
| All shares referencing the data are dropped or updated, and all historic [snapshots](/concepts/snapshots) referencing the data are deleted | Historical → Retained for Clone or Failsafe |
| Data is deleted from all zero-copy-cloned databases | Retained for Clone → Failsafe |
| Failsafe retention period passes (7 days for Standard, 1 day for Transient) | Failsafe → Deleted |

An organization is billed based on the average of active, historical, retained for clone, and failsafe bytes across all of their databases over the billing period.

Refer to the [data recovery](/concepts/data-recovery) overview for more details on how to manage historical snapshots.

### How this affects your data strategy

Understanding the storage lifecycle helps you make informed decisions about:

- **Data deletion strategies**: When you delete data, it doesn't immediately reduce your bill due to the retention stages
- **Sharing considerations**: Shared data remains in historical bytes until shares are updated or dropped
- **Cloning decisions**: [Zero-copy clones](/docs/sql-reference/motherduck-sql-reference/create-database/) can keep data in retained for clone bytes even after deletion from the source
- **Cost optimization**: Different lifecycle stages have different cost implications and management strategies

For more information on data sharing, see [Sharing Data](/key-tasks/sharing-data/sharing-overview). For details on zero-copy cloning, refer to [MotherDuck Architectural Concepts](/concepts/database-concepts/#motherduck-architectural-concepts).

## Storage management

MotherDuck databases support two options for configuring storage retention.

The first option is `SNAPSHOT_RETENTION_DAYS`. This setting allows a user to specify how many days historical snapshots should be retained for data recovery and time travel (see [Data Recovery](/concepts/data-recovery)). The recommended minimum is at least 1 day, such that you can recover your data if you accidentally drop or overwrite it. The max historical retention period you can set depends on your current plan (see below).

The second option is setting a database to be `TRANSIENT`. This setting controls the failsafe period of the database, and has different historical retention period limits. `TRANSIENT` databases are only available to Lite and Business plans.

To see the historical retention and transient status of your databases, use the [`md_information_schema.databases`](/sql-reference/motherduck-sql-reference/md_information_schema/databases) view.

Lite starts in free-tier mode with no historical retention until usage limits are reached, after which Lite defaults apply.

### Standard databases:

| Plan     | Failsafe Period: `failsafe_bytes` | Default Historical Retention: `historical_bytes` | Minimum Historical Retention: `historical_bytes` | Maximum Historical Retention: `historical_bytes` |
|----------|-------------------------------------|------------------------------|------------------------------|------------------------------|
| **Business** | 7 days                              | 7 days                        | 0 days                       | 90 days                      |
| **Lite (paid)**     | 7 days                              | 1 day                        | 1 day                        | 1 day                        |
| **Lite (free)**    | 7 days                              | 0 days                        | 0 days                       | 0 days                       |

Historical retention enables point-in-time restore for your data. Business plan users can configure retention up to 90 days for extended data recovery capabilities.

### Transient databases

For use cases that don't require the default failsafe retention period (7 days), a MotherDuck database can be set as `TRANSIENT` [at database creation](/sql-reference/motherduck-sql-reference/create-database/#database-options) to enforce a 1 day failsafe minimum. This setting can only be defined at database creation and **is not** modifiable.

| Plan     | Failsafe Period: `failsafe_bytes` | Default Historical Retention: `historical_bytes` | Minimum Historical Retention: `historical_bytes` | Maximum Historical Retention: `historical_bytes` |
|----------|----------------------------------|--------------------------------------------------|--------------------------------------------------|--------------------------------------------------|
| **Business** | 1 day                             | 1 day                                           | 0 days                                           | 90 days                                          |
| **Lite (paid)**    | 1 day                             | 1 day                                            | 1 day                                            | 1 day                                            |
| **Lite (free)**    | 1 day                             | 0 days                                           | 0 days                                           | 0 days                                           |

Transient databases will not retain data in failsafe storage. Transient databases will however still enforce a 1 day minimum lifetime for data (this will show up in your bill as failsafe).

Transient databases can be helpful for the following datasets:

* Datasets that are the intermediate output of a job (write once, read once)
* Datasets that can be reconstructed from an external data source

## Breaking down storage usage

To better understand your organization's storage bill, start with the [`STORAGE_INFO` view](/sql-reference/motherduck-sql-reference/md_information_schema/storage_info) in the [MD_INFORMATION_SCHEMA](/sql-reference/motherduck-sql-reference/md_information_schema/introduction). This function returns an overview of the storage footprint by lifecycle stage for the databases in your organization.

### _Active bytes_ are higher than expected
Consider whether you need all of the data stored in that database. Some common ways to decrease active bytes are to delete the data or optimize sorting and data types.

### _Historical bytes_ are higher than expected
You should look into either outstanding manually updated shares referencing this database in the organization or your historical database snapshots. Outstanding manually updated shares may keep historical data referenced (which prevent it from being deleted). Your historical byte footprint will decrease as the shares are updated (`UPDATE SHARE`) or dropped. You can find all shares that reference some database by using the [OWNED_SHARES](/sql-reference/motherduck-sql-reference/md_information_schema/owned_shares) view in the [MD_INFORMATION_SCHEMA](/sql-reference/motherduck-sql-reference/md_information_schema/introduction).

Otherwise you can consider reducing the `SNAPSHOT_RETENTION_DAYS` on your database to reduce the number of historical snapshots you retain. Note that this will reduce the window of time that you can restore data from. See [data recovery](/concepts/data-recovery) for more details on how to plan and setup a proper data recovery protocol for your organization.

### _Retained for clone bytes_ are higher than expected
Consider whether there are other databases that were zero-copy cloned from this database that are still referencing deleted data. This footprint will decrease as you delete the cloned data from these other databases.

### _Failsafe bytes_ are higher than expected
Failsafe bytes result from deleting data. This footprint should drop if this was a one-time deletion of data. If failsafe bytes remain consistently high - it is likely that you are overwriting or updating data too frequently. Common workloads that tend to delete a lot of data (through overwrites or updates) are: create or replace tables, truncate and insert, updates, and deletes. Avoiding these workload patterns can reduce your failsafe footprint. You can also consider using a [`TRANSIENT` database](#transient-databases), which won't have failsafe bytes, if they are applicable for your use case.

If you have the Admin role, you can view your organization's storage breakdown on the [databases page](https://app.motherduck.com/settings/databases).

If you need help understanding or reducing your storage bill, please reach out to [MotherDuck support](https://motherduck.com/contact-us/support/).