n8n PostgreSQL Bloat: Execution Data Pruning and Cleanup

n8n PostgreSQL Bloat

Self-hosted n8n instances write a database row for every workflow run, and those rows accumulate faster than most teams expect. n8n PostgreSQL bloat happens when execution data fills the database and deleted rows continue occupying disk space, causing slow execution lists, longer backups, rising storage costs, and eventually a full volume. Pruning is enabled by default, but pruning alone does not return disk space to the operating system.

Whether you run a single container or a queue-mode cluster across multiple workers, controlling execution data is essential for stable performance. Organisations running automation at production volume often Hire n8n Developers to configure retention correctly, tune PostgreSQL maintenance, and build export pipelines that satisfy audit requirements without letting the database grow without limit.

Why n8n PostgreSQL Bloat Happens

n8n stores the complete input and output of every node in every saved execution. It also stores a full snapshot of the workflow definition alongside each run, so a large workflow duplicates its own JSON on every execution.

Separately, PostgreSQL never erases a deleted row immediately. It marks the row version dead so that in-flight transactions still see a consistent snapshot, and the space is only made reusable later by VACUUM. The file on disk stays the same size.

Common causes include:

• Saving execution data for successful runs that nobody reads

• Manual test executions from the editor landing in the production database

• Large API payloads passing through many nodes

• Workflow snapshots duplicated on every single run

• Dead tuples accumulating faster than autovacuum reclaims them

• Long-running transactions or stale replication slots blocking VACUUM

• Binary data stored inside the database instead of on disk or object storage

This produces two separate problems — uncontrolled growth and unreclaimed disk space — and each needs a different fix.

Common Sources of n8n Database Growth

Some of the most frequent contributors include:

• Successful executions saved by default → duplicated storage of routine runs

• Node progress saving enabled → a write after every node instead of once per run

• Manual executions saved → developer test runs stored in production

• Waiting executions → never eligible for pruning while status stays waiting

• Annotated executions → tagged or rated runs are never pruned at all

• Workflow history → previous workflow versions retained under separate settings

• Insights tables → performance metrics retained for up to 365 days by default

• Orphaned binary data → pruning only cleans the currently active storage mode

Identifying which of these applies to your instance determines whether you need a configuration change or a full cleanup.

How to Diagnose n8n PostgreSQL Bloat

Run these before changing any settings. Growth and bloat look identical on a disk usage graph and require opposite responses.

sql-- Where is the space? Note that pg_relation_size EXCLUDES TOAST storage, -- which is where most execution data actually lives. SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total, pg_size_pretty(pg_relation_size(relid)) AS heap, pg_size_pretty(pg_indexes_size(relid)) AS indexes FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;

sql-- Dead tuples and vacuum history SELECT relname, n_live_tup, n_dead_tup, last_autovacuum FROM pg_stat_user_tables WHERE relname IN ('execution_entity', 'execution_data', 'execution_metadata') ORDER BY n_dead_tup DESC;

sql-- Is anything blocking VACUUM from reclaiming space? -- A stale replication slot will make autovacuum useless no matter how it is tuned. SELECT slot_name, active, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS wal_retained FROM pg_replication_slots;

Key Settings for n8n Execution Data Pruning

1. EXECUTIONS_DATA_PRUNE

Enables rolling deletion of finished executions. Defaults to true.

1. EXECUTIONS_DATA_MAX_AGE

The age in hours before a finished execution qualifies for deletion. Defaults to 336 (14 days).

1. EXECUTIONS_DATA_PRUNE_MAX_COUNT

The maximum number of executions kept in the database. Defaults to 10000; set to 0 for unlimited.

1. EXECUTIONS_DATA_SAVE_ON_SUCCESS

Whether successful runs are stored. Defaults to all. Setting this to none is usually the single largest saving available.

1. EXECUTIONS_DATA_SAVE_ON_PROGRESS

Whether n8n writes after every node rather than once per run. Defaults to false and should stay there.

1. EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS

Whether editor test runs are persisted. Defaults to true. Disable this on instances where developers build workflows.

1. N8N_EXECUTION_DATA_STORAGE_MODE

Where payloads are stored. Defaults to database. Switching to filesystem removes payload volume from PostgreSQL entirely and requires no paid plan.

A practical production configuration:

yamlservices: n8n: environment: - EXECUTIONS_DATA_PRUNE=true - EXECUTIONS_DATA_MAX_AGE=168 - EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000 - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none - EXECUTIONS_DATA_SAVE_ON_ERROR=all - EXECUTIONS_DATA_SAVE_ON_PROGRESS=false - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false - N8N_EXECUTION_DATA_STORAGE_MODE=filesystem - N8N_STORAGE_PATH=/data/storage

Retention can also be configured per workflow in the workflow settings panel, which is the correct place to handle exceptions such as finance or compliance workflows that need longer history.

Real Business Scenarios

Small Single-Node Instances

A few thousand executions per day on one container. Disable saving of successful runs, reduce retention to seven days, and let autovacuum handle the rest. No manual cleanup required.

High-Volume Queue Mode Deployments

Tens of thousands of runs across multiple workers. Pruning runs on the main instance rather than on workers, so an undersized main node will fall behind regardless of worker count. Move payload storage to the filesystem to reduce database pressure.

Regulated Environments

Where deletion is restricted, export execution metadata to a data warehouse or object storage on a schedule, then prune aggressively. Execution annotations should never be used as a retention mechanism, because annotated executions are never pruned.

Post-Incident Cleanup

An instance neglected for months may hold hundreds of gigabytes. Back up first, delete in bounded batches, rebuild the table, tune autovacuum, then correct the retention settings.

Multi-Tenant and Agency Deployments

Where several clients share an instance, per-workflow retention settings prevent one high-volume client from consuming the storage budget of every other.

Why Businesses Choose Professional Database Optimisation

Although n8n provides retention settings out of the box, production deployments involve PostgreSQL tuning, replication behaviour, storage architecture, and compliance requirements that default configuration does not address.

At this stage, many businesses Hire n8n Developers to audit the database, size the remediation correctly, and implement changes without interrupting live automation.

Clearing a Large Backlog Safely

When millions of rows have already accumulated, lowering the retention window and waiting is not enough — the pruning job deletes in batches on a timer and will compete with production writes for days.

Delete manually in bounded batches during a quiet window, removing child rows before parent rows:

sql-- Repeat each block until it reports 0 rows affected. DELETE FROM execution_data WHERE "executionId" IN ( SELECT id FROM execution_entity WHERE "stoppedAt" < NOW() - INTERVAL '30 days' LIMIT 10000 ); DELETE FROM execution_entity WHERE id IN ( SELECT id FROM execution_entity WHERE "stoppedAt" < NOW() - INTERVAL '30 days' AND status NOT IN ('new', 'running', 'waiting') LIMIT 10000 );

Once the rows are removed, the disk space still needs reclaiming. VACUUM FULL returns the space but holds an exclusive lock for the duration and requires free disk roughly equal to the final table size. pg_repack performs the same rebuild online with only brief locks, which is the appropriate choice on an instance that cannot be taken down.

Best Practices for n8n PostgreSQL Maintenance

Follow these recommendations for long-term stability:

• Disable saving of successful executions unless they are actively reviewed.

• Set retention to the window your team genuinely uses, not the default.

• Keep manual execution saving switched off in production.

• Move execution payloads to filesystem or object storage on high-volume instances.

• Tune autovacuum on

  execution_data

  , including its TOAST table, which is routinely missed.

• Monitor dead tuple counts rather than only disk usage.

• Check for stale replication slots before attempting any reclamation.

• Take a verified backup before any bulk deletion.

• Document retention decisions so they survive team changes.

These practices prevent recurrence rather than treating the symptom.

Scaling n8n Database Performance

As automation volume grows, database maintenance becomes an infrastructure concern rather than a configuration detail. Larger deployments typically combine:

• Filesystem or object storage for execution payloads

• Per-workflow retention policies

• Per-table autovacuum tuning

• Scheduled export of execution metadata for audit

• Monitoring on table size, dead tuples, and replication lag

• Separate maintenance windows for reclamation work

• Alerting that triggers before the volume reaches capacity

With this architecture in place, n8n can sustain high daily execution volume without the database becoming the limiting factor.

Why Choose N8n Developers?

N8n Developers provides experienced engineers who design, deploy, and maintain production n8n environments. From PostgreSQL performance tuning and execution data architecture to queue-mode scaling and compliance-driven retention pipelines, our team builds automation infrastructure that stays stable as volume grows. Whether you need a one-time database audit, a remediation plan for an instance already at capacity, or ongoing operational support, we deliver solutions built for long-term reliability.

Future of n8n Database Management

As n8n deployments move from departmental tools to core business infrastructure, execution data is increasingly treated as operational telemetry rather than disposable logs. Teams are separating hot storage for recent debugging from long-term archives in data warehouses, and applying the same monitoring discipline to automation databases that they already apply to application databases.

Organisations planning for this shift frequently Hire n8n Developers to design storage and retention architecture before volume becomes a problem rather than after.

If your n8n database is growing faster than expected, running slowly, or approaching capacity, our team can help. Hire n8n Developers today to audit your instance, implement safe cleanup, and put retention architecture in place that scales with your automation.

Managing n8n PostgreSQL bloat requires addressing two separate problems: the volume of data being written and the disk space that deleted rows continue to occupy. Correct retention settings stop future growth, autovacuum tuning keeps reclaimed space usable, and a controlled rebuild recovers space already lost. Diagnose before changing anything, because growth and bloat present identically and respond to opposite fixes. With the right configuration in place, most instances never need manual intervention again.