Prune n8n Execution Data | How to clean up the N8N database?

Managing automation at scale isn’t just about building workflows; it’s about keeping your infrastructure lean and responsive. Without a plan for execution data, n8n’s database gradually fills with logs from every run. This causes sluggish loading, higher storage bills, and fragile debugging. The good news? n8n already includes tools to trim the fat. This guide walks through the reasons why pruning matters, how to set it up, and best practices for keeping your instance fast and affordable.

Why pruning matters – pains and payoffs?

Pain

• Sluggish workflows – Execution logs accumulate in the execution_entity table, making every query slower. When the database is large, the “Executions” tab crawls and workflows take longer to start. Community members have reported Postgres ballooning to gigabytes within weeks, and SQLite can even lock or corrupt.
• Growing storage costs – Each saved run includes JSON payloads, binary files, timestamps and error details. Backups take longer and disk snapshots swell. If left unchecked, cloud plans automatically prune older logs after a limit but heavy workloads can still hit capacity.
• Debugging headaches – Keeping every run might seem safe, but rummaging through thousands of entries slows triage. Sensitive data also lingers unnecessarily.

AI‑powered fix

• Automated pruning – n8n has built‑in retention rules. It deletes finished executions and binary data once they exceed an age or count threshold. You can adjust these thresholds globally or per workflow.
• Targeted retention – Use workflow settings to disable saving successful runs or shorten retention for non‑critical flows. Environment variables like EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT give you granular control.
• Periodic maintenance – Scheduling vacuum operations for SQLite or running custom Postgres scripts clears freed space, keeping the database lean.

Payoff

• Faster automation – Small tables respond quickly. The editor loads instantly and webhooks fire without delays.
• Lower infrastructure spend – By storing only what you need, you reduce disk usage and database costs.
• Reliable debugging – Keeping only relevant runs makes tracing issues quicker and prevents sensitive data from persisting longer than necessary.

How does n8n handle execution data?

Every time a workflow runs, n8n writes an entry to your database. Each record captures the workflow ID, start/stop timestamps, status, input/output payloads and errors. This data is invaluable during development and troubleshooting but becomes burdensome at scale.

Built‑in pruning logic

n8n prunes finished executions when either of two conditions are met:

• Age‐based pruning – If an execution finished more than EXECUTIONS_DATA_MAX_AGE hours ago, it becomes eligible for removal. The default is 336 hours (14 days).
• Count‐based pruning – If the number of stored executions exceeds EXECUTIONS_DATA_PRUNE_MAX_COUNT, n8n deletes the oldest ones first. The default is 10 000 runs.

Pruning skips runs with the status new, running or waiting, ensures annotated executions remain, and waits for a hard delete buffer (default 1 hour) so recent runs stay available. On n8n Cloud, automatic pruning is governed by your plan—starter plans keep 2 500 executions or 7 days, Pro/Power plans store up to 25 000 or 30 days, and Enterprise scales to 50 000 with unlimited retention.

Database considerations

Your choice of database influences how pruning works:

Database	Pros	Cons	Note
SQLite	Simple, file‑based; great for local development	Doesn’t automatically free disk space after deleting rows; pruned data remains until a VACUUM is rundocs.n8n.io	Use DB_SQLITE_VACUUM_ON_STARTUP to automatically vacuum on startu
PostgreSQL	Scales well for production; supports concurrent access	Requires periodic maintenance (VACUUM ANALYZE) and indexing to reclaim space	Use separate tables or cron jobs to archive summaries

Because SQLite reuses freed pages instead of releasing them to the filesystem, running VACUUM after pruning is essential. Postgres, on the other hand, benefits from autovacuum but still requires manual vacuuming under heavy load to reduce bloat.

Configuring execution data retention

n8n offers two ways to configure retention: per‑workflow settings through the UI and environment variables for global control.

Via the n8n user interface

1. Open a workflow and click the Options menu → Settings.
2. In the Save successful production executions field, choose Do not save if you only care about failures or debugging runs.
3. For each workflow, set different retention periods to align with its importance and compliance requirements.

Reducing saved successful runs dramatically decreases database growth and makes subsequent pruning easier. When you’re self‑hosting on n8n Cloud, these settings complement the automatic limits of your plan.

Via environment variables

A declarative way to manage retention is through environment variables. The key ones are summarized below (defaults shown in parentheses):

Variable	Purpose	Example
EXECUTIONS_DATA_PRUNE (true)	Enables automatic pruning	EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE (336)	Maximum age (hours) before a finished execution is deleted	EXECUTIONS_DATA_MAX_AGE=168 (7 days)
EXECUTIONS_DATA_PRUNE_MAX_COUNT (10000)	Cap on total stored executions; 0 disables count‑based pruning	EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
EXECUTIONS_DATA_HARD_DELETE_BUFFER (1)	Safety buffer (hours) before hard deletion	EXECUTIONS_DATA_HARD_DELETE_BUFFER=1
EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL (60)	Frequency (minutes) for soft deletion	EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL=60
EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL (15)	Frequency (minutes) for hard deletion	EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL=15
EXECUTIONS_DATA_SAVE_ON_SUCCESS (all)	Whether to save full data on success (all or none)	EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR (all)	Save data on error	EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_PROGRESS (false)	Save progress at each node	EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS (true)	Save data from manual runs	EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

On hosted platforms like Railway, adjusting these variables can prevent bloat. For instance, Horizon’s performance guide recommends disabling saving of successful executions and shortening EXECUTIONS_DATA_MAX_AGE from the default 10 days to 3 days for high‑volume systems.

To enable pruning in Docker, add the variables when launching the container:

# enable pruning with a 7‑day retention, keep up to 50k executions
docker run -d --name n8n -p 5678:5678 \
  -e EXECUTIONS_DATA_PRUNE=true \
  -e EXECUTIONS_DATA_MAX_AGE=168 \
  -e EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000 \
  n8nio/n8n

Consider retention by plan on n8n Cloud

If you’re using n8n Cloud, keep in mind that the platform automatically applies limits. Start and Starter plans keep up to 2 500 executions with a 7‑day log, while Pro/Power plans store up to 25 000 executions for 30 days and Enterprise scales to 50 000 with unlimited retention. Heavy workloads may still exceed capacity; when disk usage passes 85 %, n8n’s team will manually prune by restoring a backup without execution data.

Manually deleting execution data

Sometimes you need to clear space immediately. n8n provides two approaches:

Using the n8n UI

1. Navigate to Executions in the left‑hand menu.
2. Filter by status (e.g. Failed, Stopped or Success) and date range to target old or unnecessary runs.
3. Select individual entries or entire batches and click Delete. Confirm your choice—deleted execution data cannot be restored.

This method is quick and safe for occasional cleanup. However, it’s tedious when thousands of runs need removal.

Programmatic deletion with SQL or Command Nodes

For large‑scale cleanups, you can script deletions. A SQL query like below removes executions older than 30 days; adapt interval to your retention policy:

-- Delete executions older than 30 days
DELETE FROM execution_entity
WHERE "startedAt" < NOW() - INTERVAL '30 days';

Mark O’Connor’s pruning guide suggests storing summaries in a separate table before deleting payloads. This preserves basic audit data (workflow ID, status, timestamps) while cutting storage usage. Always back up your database before running such scripts.

Alternatively, build a dedicated n8n workflow: use the List Executions node to fetch runs, an If node to compare the start date against a retention threshold, and the Delete Execution node to remove those beyond the threshold. The official template “Automatically prune n8n execution history” runs daily, deleting runs older than 10 days and can be customised to your own retention period.

Automating pruning and maintenance

Schedule cleanup workflows

Automation ensures you don’t forget to prune. A typical workflow for self‑hosted deployments might include:

1. Schedule Trigger – runs daily or weekly.
2. List Executions – retrieves runs for a specific workflow or the entire system.
3. If Node – checks whether each run’s start date is older than your retention threshold.
4. Delete Execution – deletes the run if it’s outdated; otherwise, does nothing.

Fine‑tune the retention period by changing the date comparison (for example, 10 * 24 * 60 * 60 * 1000 for 10 days). You can also adjust the schedule to run during low‑traffic hours.

Reduce execution volume at the source

Pruning is only part of the picture. Reduce the amount of data being stored in the first place:

• Disable saving successful runs – Set EXECUTIONS_DATA_SAVE_ON_SUCCESS=none or uncheck the option in workflow settings. Save only failed runs for debugging.
• Limit manual execution saves – Unless you’re actively troubleshooting, disable saving manual runs (EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false).
• Trim payloads – Filter data early in your workflow to avoid carrying unnecessary fields. Batch operations rather than looping through individual items can also reduce the number of executions.
• Use external storage for binary data – n8n prunes binary files based on the active storage mode (S3, filesystem, etc.). Offload large binaries to long‑term storage and delete them when no longer needed.

Maintain your database

• Vacuum regularly – In SQLite, freed space is not released back to the filesystem until a VACUUM runs. Set DB_SQLITE_VACUUM_ON_STARTUP=true to vacuum automatically or schedule a periodic vacuum. In PostgreSQL, monitor table bloat and run VACUUM ANALYZE or VACUUM FULL during off‑peak hours to reclaim disk and update statistics.
• Index key fields – Add indexes to columns like startedAt, status and workflowId to speed up queries.
• Monitor metrics – Track database size, table bloat and queue depth. Tools like Prometheus and Grafana help you visualise trends.

Frequently asked questions

Wrapping up

Pruning execution data is an essential part of n8n maintenance. By understanding how n8n stores runs and configuring retention through the UI or environment variables, you can keep your instance responsive and cost‑efficient. Remember to tailor retention periods to each workflow, schedule regular cleanup jobs, and vacuum your database. These small habits pay off in faster automation, lower costs, and easier debugging. Start implementing these strategies today and turn your n8n server into a lean, resilient automation engine.