Why the n8n Database Grows: Cleaning Up Execution Data

With every workflow run, n8n stores execution data in its own database, and without cleanup this database often grows quickly to several gigabytes with active workflows. The solution is called Execution Data Pruning: n8n automatically deletes completed executions once they are older than a defined number of hours or the total number of stored executions exceeds a limit. This behavior is controlled via environment variables such as EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE, and EXECUTIONS_DATA_PRUNE_MAX_COUNT, which are set directly in the configuration for self-hosted n8n instances. As of: July 2026.

Why does the n8n database grow so quickly through executions?

Every execution of a workflow creates a record with the input, output, and status of each individual node, and with several hundred runs per day this quickly adds up to a considerable amount of data. By default, n8n stores both successful and failed executions of published workflows as well as manual test runs from the editor. Anyone running many workflows with a high trigger frequency, such as hourly synchronizations or webhook-driven processes, notices the growth especially clearly in the loading times of the executions list and the size of the database file. According to the official n8n documentation, pruning is therefore enabled by default so that the database does not grow uncontrollably.

What exactly does the EXECUTIONS_DATA_PRUNE setting do?

EXECUTIONS_DATA_PRUNE is a boolean switch with the default value true, which determines whether n8n automatically deletes completed executions at all. If the variable is active, n8n first marks old executions for deletion (soft delete) and then removes them permanently (hard delete). According to the documentation, this two-stage approach serves performance, because the actual deletion happens in the background without blocking ongoing operation. Details of the exact process are described in the n8n documentation on Managing Execution Data.

Which environment variables determine how long data is retained?

Pruning kicks in as soon as one of two conditions is met: the age of an execution exceeds a limit, or the total number of stored executions exceeds a limit. The relevant variables are documented in the Executions reference.

• EXECUTIONS_DATA_MAX_AGE: age in hours after which a completed execution is marked for deletion, default value 336 hours, i.e. 14 days.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: maximum number of executions that should remain in the database, default value 10,000, the value 0 means no limit.
• EXECUTIONS_DATA_HARD_DELETE_BUFFER: safety buffer in hours, default value 1, which deliberately excludes very recently completed data from permanent deletion so that it remains available for troubleshooting.
• EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL / EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL: how often, in minutes, the respective deletion run starts, default values 15 and 60 minutes respectively.

For SQLite as the database, the documentation gives an additional important note: the disk space freed up by pruning is reused internally by SQLite, but not automatically returned to the operating system. To actually free up the disk space, n8n recommends either setting the environment variable DB_SQLITE_VACUUM_ON_STARTUP or manually running the VACUUM command.

Which executions are never deleted automatically?

Not every execution is subject to cleanup. According to the documentation, executions with the status new, running, or waiting are excluded from deletion because they are not yet completed. In addition, annotated executions, that is, those that have been given tags or a rating in the editor, are kept permanently. This is useful for specifically protecting individual important test runs or conspicuous errors from automatic deletion without disabling pruning entirely.

How do you determine per workflow what is actually stored?

Before pruning even applies, the workflow setting decides whether an execution is stored at all. In the workflow editor, you open the Settings item via the three-dot menu at the top right and separately determine there whether failed, successful, and manual executions should be stored. In addition, the Save execution progress option controls whether n8n saves the state of each individual node during the run, which according to the documentation can increase latency but in return allows a restart at the point of failure. For productive workflows with high volume, it is worth checking exactly which executions are really relevant in the long term before adjusting the global prune variables. For n8n automation by NordFlux, this configuration is part of the standard server-side setup, so that the database of a self-hosted system remains permanently performant and data sovereignty stays with the customer.

Frequently asked questions about n8n Execution Data Pruning

What happens if I disable EXECUTIONS_DATA_PRUNE?

If the variable is set to false, n8n no longer automatically deletes any executions, and the database keeps growing without limit. This can be useful for short test phases or debugging, but is risky in ongoing operation because the database file will eventually push performance and disk space to their limits. For productive instances, it is recommended to leave pruning enabled and instead adjust EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT to your own needs.

How quickly do completed executions actually disappear from the database once the prune limit is reached?

This depends on the configured intervals: by default, n8n checks for soft-delete candidates every 60 minutes and runs the final hard delete every 15 minutes. In addition, the hard-delete buffer, one hour by default, ensures that very recently completed executions do not disappear immediately. In practice, depending on the configuration, it therefore takes up to a few hours for an execution to actually leave the database.

Can I protect individual important executions from automatic deletion?

Yes, annotated executions, that is, those with tags or a rating in the n8n editor, are excluded from automatic cleanup according to the documentation. This is suitable for keeping individual conspicuous error cases or reference runs permanently traceable without disabling global pruning. Automatic deletion nevertheless remains active for the bulk of routine executions.

Do I still need to do anything manually with SQLite after pruning?

Yes, because SQLite does not automatically return deleted disk space to the operating system, but continues to use it internally for future executions. Anyone who actually wants to reduce the disk space used should, according to the n8n documentation, either set DB_SQLITE_VACUUM_ON_STARTUP or occasionally run the VACUUM command manually. With PostgreSQL as the database, this problem is generally less pronounced, since its storage management works differently.