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
braham
2
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
system
Closed
3
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.