Pruning executions в n8n: очистка истории запусков, размер базы и производительность

Обновлено: 2026-05-29

История executions в n8n полезна для отладки, но на рабочем инстансе она быстро превращается в источник проблем: растёт PostgreSQL, заканчивается диск, замедляется список запусков, дольше идут backup и restore, а failed executions становится сложнее разбирать. Pruning executions нужен не для “красоты”, а для нормальной эксплуатации self-hosted n8n.

Правильная настройка зависит от роли инстанса. Учебному n8n достаточно хранить историю несколько дней. Бизнес-инстансу с заявками, платежами и CRM нужна политика хранения: что оставляем для аудита, что удаляем, что выгружаем в отдельный лог или S3/MinIO, а что вообще нельзя писать в execution data.

Что именно разрастается

Базовая политика хранения

Не начинайте с env-переменной. Сначала решите, зачем вам история:

• Отладка новых workflow: хранить 7–14 дней, включать больше данных только на время разработки.
• CRM и заявки: хранить техническую историю 14–30 дней, а бизнес-события писать отдельно в Postgres, CRM или audit log.
• Платежи и юридически значимые события: не полагаться на execution history как на журнал учёта; сохранять payment_id, order_id, статус и подпись события в отдельную таблицу.
• AI/RAG: не хранить большие prompt/context/output бесконечно; логировать минимум для расследования и стоимости.

Env-переменные для pruning

В n8n pruning включён по умолчанию, но на self-hosted инстансе параметры лучше задать явно, чтобы поведение было воспроизводимым после переезда или обновления.

services:
  n8n:
    environment:
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336
      - EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
      - EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
      - EXECUTIONS_DATA_SAVE_ON_ERROR=all

EXECUTIONS_DATA_MAX_AGE задаётся в часах: 336 часов — это 14 дней. EXECUTIONS_DATA_PRUNE_MAX_COUNT полезен как дополнительный ограничитель, если workflows запускаются очень часто. Не ставьте значения наугад: сначала оцените частоту запусков и размер базы.

Когда не стоит хранить все успешные executions

Для потоковых workflow, которые каждые 1–5 минут проверяют API, успешные executions редко нужны полностью. В таких сценариях лучше хранить ошибки и отдельный бизнес-лог:

{
  "workflow": "sync-orders",
  "external_id": "order_12345",
  "status": "processed",
  "source": "tilda",
  "target": "bitrix24",
  "processed_at": "2026-05-29T10:15:00+03:00"
}

Такой audit log можно писать в PostgreSQL, Google Sheets для малого проекта или отдельный observability-стек. Execution history тогда остаётся инструментом диагностики, а не единственным источником правды.

Как понять, что база уже распухла

Для PostgreSQL начните с размера базы и самых крупных таблиц:

SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;

SELECT relname,
       pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 15;

Если вверху таблицы execution data, pruning действительно нужен. Если растут другие таблицы, причина может быть не в истории запусков, а в workflow, который пишет дубли в собственные таблицы.

Binary data: отдельная зона риска

Файлы в n8n опаснее обычного JSON: одно письмо с PDF-вложением или webhook с изображением может занимать больше места, чем сотни простых запусков. Если workflows активно работают с файлами, продумайте хранение заранее:

• не держите большие вложения в execution history дольше необходимого;
• перекладывайте файлы в S3/MinIO, Google Drive, Яндекс Диск или Nextcloud;
• в execution data сохраняйте ссылку, hash, размер и внешний ID;
• не логируйте персональные документы без причины.

Безопасная очистка без сюрпризов

1. Сделайте backup PostgreSQL и volume с binary data.
2. Зафиксируйте текущий размер базы и диска.
3. Задайте retention, например 14 или 30 дней.
4. Перезапустите n8n.
5. Через несколько часов проверьте, уменьшилось ли количество старых executions.
6. Если место на диске не вернулось, проверьте PostgreSQL vacuum и storage на уровне провайдера.

Важно: удаление строк в PostgreSQL не всегда сразу уменьшает размер файлов на диске. Это нормальное поведение. Цель pruning — остановить бесконтрольный рост и ускорить работу, а не мгновенно “сжать” базу после многомесячного накопления.

Типовые ошибки

Практический минимум для рабочего инстанса

• retention 14–30 дней для большинства workflows;
• отдельный audit log для заявок, оплат и критичных интеграций;
• алерт на свободное место диска;
• еженедельная проверка размера PostgreSQL;
• регулярный restore-drill, чтобы backup не был декоративным.

Если n8n используется как центральный интеграционный слой бизнеса, pruning — это часть архитектуры, а не разовая уборка. Без него через несколько месяцев даже хороший VPS может начать тормозить из-за истории запусков, которую никто не читает.

docker compose ps
docker compose logs --tail=200 n8n
docker compose logs --tail=200 n8n-worker
printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_'
# перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY

Связанные материалы

• PostgreSQL для n8n
• Backup и restore n8n
• Логи и мониторинг n8n
• S3 и MinIO для файлов