Skip to main content
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.