Managing n8n Execution Data Retention and Storage Overhead

Self-hosting n8n provides engineering teams with complete operational control, but unmanaged execution data can steadily consume disk capacity. Whether workflows persist payload data depends on configured execution save settings. Without structured pruning policies, database tables expand over time, creating unnecessary storage overhead on production hosts.

Official Pruning Mechanics

According to official n8n documentation, execution pruning is enabled by default (EXECUTIONS_DATA_PRUNE=true). The pruning process periodically removes finished execution entries based on maximum age in hours (EXECUTIONS_DATA_MAX_AGE, defaulting to 336 hours, which equals 14 days) or maximum execution count (EXECUTIONS_DATA_PRUNE_MAX_COUNT, defaulting to 10,000). Executions marked with manual annotations, waiting executions, running jobs, or newly initiated runs are not automatically pruned. In SQLite setups, deleting rows frees space internally for database reuse; reclaiming physical file space can be scheduled via DB_SQLITE_VACUUM_ON_STARTUP=true or an explicit vacuum operation.

Illustrative Sizing Model (Author Hypothesis)

Storage requirements depend heavily on workflow payload volume and whether intermediate node states are recorded. To illustrate potential storage accumulation, consider a hypothetical deployment:

• Daily throughput: 500 workflow runs per day handling webhooks.
• Sampled execution size: 2 MB average recorded size per run (including payload data and node outputs).
• Configured retention window: 7 days (set via EXECUTIONS_DATA_MAX_AGE=168).

Under these specific modeling assumptions, estimated active storage usage calculates as:

If retained across the default 14-day window (336 hours), this hypothetical accumulation reaches approximately 14 GB. Actual disk demand will vary depending on payload size and individual node save configurations.

Pragmatic Retention Planning

Teams should audit execution data policies based on troubleshooting requirements and data sensitivity:

• Minimum necessary diagnostics: Retain error details (EXECUTIONS_DATA_SAVE_ON_ERROR=all) based on the minimum period required for debugging, while ensuring sensitive customer credentials or tokens are not inadvertently stored in cleartext.
• Success payload suppression: For frequent polling or health-check routines, setting EXECUTIONS_DATA_SAVE_ON_SUCCESS=none avoids writing megabytes of repetitive routine logs.
• Database engine considerations: High-throughput environments may benefit from PostgreSQL for concurrent access. However, PostgreSQL autovacuum primarily marks space for internal table reuse rather than instantly shrinking OS disk footprints, so capacity planning remains essential.