Prune Execution Data to Prevent Database Bloat

Every workflow execution stores its full input/output data in the database by default. After a few weeks of active use, the executions table can grow to tens of gigabytes, slowing down the entire n8n interface and eventually filling your disk.

Real-world example: A production n8n instance running 200 workflows became unusably slow after 3 months. Investigation revealed 2.8 million execution records consuming 47 GB of database storage.

# .env configuration for execution pruning

# Enable automatic pruning

EXECUTIONS_DATA_PRUNE=true

# Keep successful executions for 7 days

EXECUTIONS_DATA_MAX_AGE=168

# Keep only the last 5000 executions regardless of age

EXECUTIONS_DATA_PRUNE_MAX_COUNT=5000

# Prune check interval in minutes (default: 15)

EXECUTIONS_DATA_PRUNE_TIMEOUT=15
```text
For high-volume deployments, combine pruning with selective saving:

```bash

# Don't save data for successful executions at all

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none

# Always save data for failed executions (for debugging)

EXECUTIONS_DATA_SAVE_ON_ERROR=all

# Save manual executions (useful for development)

EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true
```text
| Scenario | Recommended Settings |
|:---------|:--------------------|
| Development | Save all, prune after 30 days |
| Production (low volume) | Save all, prune after 7 days, max 10k |
| Production (high volume) | Save failures only, prune after 3 days |
| Compliance-required | Save all, prune after retention period, use external log export |

**Related:** [Flatten Deeply Nested API Responses](../code-node-mastery/01-flatten-deeply-nested-api-responses.md) | [Use Docker Compose with Health Checks for n8n and PostgreSQL](../self-hosting-operations/01-use-docker-compose-with-health-checks-for-n8n-and-postgresql.md)