> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alumio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Storages

> Storages let you save data inside Alumio, for example for caching or reuse across routes.

Storages are key-value data stores built into Alumio that let you persist data between integration runs. They are used for caching, delta filtering, pagination tracking, cross-system ID mapping, and more.

### What Storages can do

Storages give you a way to persist and retrieve data across integration runs. You can:

* Cache data between runs to avoid reprocessing unchanged records (delta filtering).
* Store and retrieve cross-system ID mappings, mutation dates, and lookup values.
* Track pagination state across Scheduler runs to enable incremental data fetching.
* Use a Storage as a data source in an Incoming configuration to process stored entities through a Route.
* Automatically prune entities older than a defined threshold to manage database size.

### Filtering Storages

The overview page lists all Storages in your environment. Filters are available for Name, Created at, Updated at, and Labels. Use **+ Add Filter** for additional conditions. Click any column header to sort.

### Creating a Storage

A Storage is configured with a name, an optional description, a storage type, logging options, and an optional pruning threshold.

**Logging** controls which entity-level events are written to the log: creating, updating, and deleting entities can each be enabled independently.

**Pruning** automatically deletes entities older than a configured threshold (time to live). This is particularly important for high-volume integrations -- running out of database storage will make your Alumio environment unavailable.

### Using Storages in integrations

Storages become useful through dedicated Entity transformers that read from and write to them during integration processing.

**Delta filtering** –– the most common use case. The `Filter previously stored entities` transformer compares each incoming entity against what is already stored. Unchanged entities are filtered out; only new or changed entities pass through and create tasks.

**Writing data** –– the `Write to storage` and `Write content to storage` transformers persist values from the current integration run into a Storage for later retrieval. Used for saving mutation dates, lookup data, pagination state, and cross-system ID mappings.

**Reading data** –– the `Get entity from storage` transformer retrieves a previously stored entity and makes it available in the current run. Used to look up values stored in a previous run, such as an ID created when a record was first written to the target system.

**Pagination tracking** –– the `Track progress in storage` and `Load progress tracker from storage` transformers work together to save and restore pagination state across Scheduler runs, enabling incremental fetching from large APIs.

**Storage subscribers** –– a Storage can act as a data source on an Incoming configuration. The `Storage subscriber` creates one task per entity; the `Merged Storage subscriber` combines all entities into a single task. Useful when downstream processing requires all records together, or when handling very large numbers of entities.