Prune n8n execution data so your database stops growing

n8n prunes execution data by default: it deletes finished executions older than 14 days (336 hours) and keeps at most 10,000 of them, whichever limit is hit first. To keep your database smaller, lower EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT, and stop saving data you never look at, such as successful runs. On SQLite, pruned space isn't returned to the disk until you vacuum the database.

The short version

• Pruning is on by default (EXECUTIONS_DATA_PRUNE=true), with a 14-day age limit and a 10,000-execution cap.
• Whichever limit hits first wins. An execution is pruned when it's too old, or when the total count is over the cap (oldest first).
• Some executions are never pruned: ones still new, running or waiting, and annotated ones (with tags or ratings).
• Pruning also deletes binary data stored with those executions.
• Save less to begin with: EXECUTIONS_DATA_SAVE_ON_SUCCESS=none keeps only failed runs. Each workflow can override this in its settings.
• SQLite keeps the file size after pruning. Set DB_SQLITE_VACUUM_ON_STARTUP=true for one restart, or run VACUUM, to shrink it.
• We tested it on n8n 2.46.6: 31 executions dropped to 10 within a minute with a cap of 10, and the SQLite file only shrank after a vacuum on restart.

Why the n8n database grows

Every saved execution stores the data each node produced. n8n's execution data docs put it plainly: "Depending on your executions settings and volume, your n8n database can grow in size and run out of storage." Their advice has two parts, which are also the two parts of this guide: don't save data you don't need, and prune old execution data.

A busy webhook workflow that runs every few seconds and passes large payloads fills the database much faster than a daily schedule. So the default limits are a starting point, not a recommendation for every instance.

How pruning works

From the docs, n8n prunes a finished execution when either of these is true:

• Age: it finished more than EXECUTIONS_DATA_MAX_AGE hours ago (default 336, which is 14 days).
• Count: the total number of executions is over EXECUTIONS_DATA_PRUNE_MAX_COUNT (default 10,000). n8n then deletes from oldest to newest.

Pruning runs in two steps, according to the pruning service in n8n's source:

1. Soft delete, every EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL minutes (default 60). It marks every execution that's past the age or count limit, skipping annotated executions. Marked executions disappear from the executions list.
2. Hard delete, every EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL minutes (default 15). It removes the marked executions in batches of 100, along with their binary data, once they're older than EXECUTIONS_DATA_HARD_DELETE_BUFFER hours (default 1).

The buffer exists, per the env var reference, because "the user may need them while building a workflow."

Three kinds of execution are never pruned: ones with the status new, running or waiting (so a workflow paused on a Wait node keeps its data), and annotated executions, "for example, executions with tags or ratings."

The pruning settings

All of these are environment variables on the n8n service. The defaults below are from the docs and match n8n's config source at 2.47.0.

For example, to keep one week and at most 50,000 executions, as in n8n's own example:

services:
  n8n:
    environment:
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000

Keep the age long enough to debug last week's failures. If your error workflow or your team needs to open a failed execution after a weekend, a 24-hour age limit will have deleted it.

Save less execution data

Pruning removes old data. The save settings decide what gets stored in the first place:

The setup the docs suggest for a lean database keeps failures and drops the rest:

services:
  n8n:
    environment:
      - EXECUTIONS_DATA_SAVE_ON_ERROR=all
      - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
      - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

The trade-off: with EXECUTIONS_DATA_SAVE_ON_SUCCESS=none, you can't open a successful run to check what it did.

Override it per workflow

The env vars set the instance defaults. Each workflow can override them in its workflow settings, with Save failed production executions, Save successful production executions, Save manual executions and Save execution progress. A practical split is to stop saving successful runs instance-wide and turn Save successful production executions back on only for the few workflows you need to audit.

Free disk space on SQLite

Pruning deletes rows, but on SQLite the file doesn't shrink. The docs say the space "isn't automatically freed up but rather reused for future executions data," and give two ways to reclaim it: the DB_SQLITE_VACUUM_ON_STARTUP variable, or SQLite's VACUUM command.

To vacuum once, set the variable, restart n8n, then remove it again:

services:
  n8n:
    environment:
      - DB_SQLITE_VACUUM_ON_STARTUP=true

Vacuuming rewrites the database file, so take a backup first. The n8n docs only cover reclaiming space for SQLite; they don't give steps for Postgres.

What we saw when we tested it

On November 6 we ran n8n 2.46.6 in Docker with the default SQLite database. To see pruning within minutes, we set EXECUTIONS_DATA_PRUNE_MAX_COUNT=10, both pruning intervals to 1 minute and EXECUTIONS_DATA_HARD_DELETE_BUFFER=0. Then we called a published webhook workflow 31 times, each run storing about 200 KB of data:

• 31 executions showed in the executions list, and database.sqlite was 8.4 MB.
• Within a minute, the list was down to 10 executions: the count limit worked as documented.
• The database file stayed at 8.4 MB after pruning, and after a normal restart.
• After a restart with DB_SQLITE_VACUUM_ON_STARTUP=true, database.sqlite was 4.7 MB. The database.sqlite-wal file next to it grew from 4.2 MB to 5.7 MB at the same time, so check the whole data folder, not just the main file, when you measure.

These intervals are for testing only. Keep the defaults, or something close, in production: pruning every minute adds database load for no benefit.

Where pruning fits with binary data and queue mode

• Binary data is deleted together with its execution, so the pruning settings also decide how long files stay on disk or in S3. Our binary data guide covers where those files live.
• Queue mode keeps executions in n8n's Postgres database like any other setup, so the same settings apply. Our queue mode guide covers the rest of a scaled setup.