Execution Data Bloat and Posters I/O spikes

After enabling execution pruning, I’m seeing heavy I/O spikes during deletion cycles. Is manual vacuuming expected for Postgres-backed setups?

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
1 Like

Yes, this is expected behavior.

When large volumes of execution rows are deleted:

Postgres marks space as reusable.

It does not immediately reclaim disk space.

This increases table fragmentation and I/O.

You should:

  • Run regular VACUUM (or rely on autovacuum tuning)
  • Consider VACUUM FULL during maintenance windows
  • Reduce retention window if execution storage is not required

This is a scaling consideration, not a workflow issue.

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.