Почему растёт база данных n8n: очистка данных выполнений

При каждом запуске workflow n8n сохраняет данные execution в собственной базе данных, и без очистки эта база данных при активных workflow часто быстро вырастает до нескольких гигабайт. Решение называется Execution Data Pruning: n8n автоматически удаляет завершённые executions, как только они становятся старше заданного количества часов или общее число сохранённых executions превышает лимит. Это поведение управляется через переменные окружения, такие как EXECUTIONS_DATA_PRUNE, EXECUTIONS_DATA_MAX_AGE и EXECUTIONS_DATA_PRUNE_MAX_COUNT, которые для самостоятельно размещённых инстансов n8n задаются напрямую в конфигурации. По состоянию на июль 2026 года.

Почему база данных n8n так быстро растёт из-за executions?

Каждое выполнение workflow создаёт запись с input, output и статусом каждого отдельного узла, и при нескольких сотнях запусков в день это быстро складывается в значительный объём данных. При этом n8n по умолчанию сохраняет как успешные, так и неудачные выполнения опубликованных workflow, а также ручные тестовые запуски из редактора. Тот, кто использует много workflow с высокой частотой триггеров, например почасовые синхронизации или процессы, управляемые webhook, особенно заметно ощущает этот рост по времени загрузки списка executions и по размеру файла базы данных. Согласно официальной документации n8n, pruning поэтому включён по умолчанию, чтобы база данных не росла бесконтрольно.

Что именно делает настройка EXECUTIONS_DATA_PRUNE?

EXECUTIONS_DATA_PRUNE это булев переключатель со значением по умолчанию true, определяющий, удаляет ли n8n вообще завершённые executions автоматически. Если переменная активна, n8n сначала помечает старые executions для удаления (soft delete), а затем окончательно удаляет их (hard delete). Согласно документации, этот двухэтапный подход служит производительности, поскольку фактическое удаление происходит в фоновом режиме, не блокируя текущую работу. Подробности точного процесса описаны в документации n8n по управлению данными executions.

Какие переменные окружения определяют, как долго хранятся данные?

Pruning срабатывает, как только выполняется одно из двух условий: возраст execution превышает лимит, либо общее число сохранённых executions превышает лимит. Соответствующие переменные документированы в справочнике по executions.

• EXECUTIONS_DATA_MAX_AGE: возраст в часах, начиная с которого завершённая execution помечается для удаления, значение по умолчанию 336 часов, то есть 14 дней.
• EXECUTIONS_DATA_PRUNE_MAX_COUNT: максимальное количество executions, которые должны оставаться в базе данных, значение по умолчанию 10 000, значение 0 означает отсутствие лимита.
• EXECUTIONS_DATA_HARD_DELETE_BUFFER: буфер безопасности в часах, значение по умолчанию 1, который намеренно исключает совсем недавно завершённые данные из окончательного удаления, чтобы они оставались доступными для устранения неполадок.
• EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL / EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL: как часто в минутах запускается соответствующий цикл удаления, значения по умолчанию 15 и 60 минут соответственно.

Для SQLite в качестве базы данных документация даёт дополнительное важное замечание: место на диске, освобождённое благодаря pruning, повторно используется SQLite внутренне, но не возвращается автоматически операционной системе. Чтобы действительно освободить место на диске, n8n рекомендует либо установить переменную окружения DB_SQLITE_VACUUM_ON_STARTUP, либо вручную выполнить команду VACUUM.

Какие executions никогда не удаляются автоматически?

Не каждая execution подлежит очистке. Согласно документации, executions со статусом new, running или waiting исключены из удаления, поскольку они ещё не завершены. Кроме того, аннотированные executions, то есть те, которым в редакторе присвоены теги или оценка, сохраняются постоянно. Это удобно для того, чтобы целенаправленно защитить отдельные важные тестовые запуски или заметные ошибки от автоматического удаления, не отключая pruning полностью.

Как задать для каждого workflow, что вообще сохраняется?

Прежде чем pruning вообще вступит в действие, настройка workflow определяет, сохраняется ли execution. В редакторе workflow для этого открывают пункт Settings через меню из трёх точек в правом верхнем углу и отдельно задают там, должны ли сохраняться неудачные, успешные и ручные executions. Кроме того, опция Save execution progress управляет тем, сохраняет ли n8n состояние каждого отдельного узла во время выполнения, что согласно документации может увеличить задержку, но зато позволяет перезапустить выполнение с места ошибки. Для продуктивных workflow с большим объёмом стоит точно проверить, какие executions действительно важны в долгосрочной перспективе, прежде чем изменять глобальные переменные pruning. В рамках автоматизации n8n от NordFlux эта настройка на стороне сервера является частью базовой настройки, чтобы база данных самостоятельно размещённой системы оставалась стабильно производительной, а суверенитет данных оставался у клиента.

Часто задаваемые вопросы об n8n Execution Data Pruning

Что произойдёт, если я отключу EXECUTIONS_DATA_PRUNE?

Если переменная установлена в false, n8n больше не удаляет executions автоматически, и база данных продолжает расти без ограничений. Это может быть полезно для коротких тестовых фаз или отладки, но рискованно при постоянной эксплуатации, поскольку файл базы данных рано или поздно достигнет предела производительности и места на диске. Для продуктивных инстансов рекомендуется оставить pruning включённым и вместо этого настроить EXECUTIONS_DATA_MAX_AGE и EXECUTIONS_DATA_PRUNE_MAX_COUNT под собственные потребности.

Как быстро завершённые executions фактически исчезают из базы данных после достижения лимита pruning?

Это зависит от настроенных интервалов: по умолчанию n8n проверяет кандидатов на soft delete каждые 60 минут и выполняет окончательный hard delete каждые 15 минут. Кроме того, буфер hard delete, по умолчанию один час, обеспечивает то, что совсем недавно завершённые executions не исчезают сразу. На практике, в зависимости от конфигурации, требуется до нескольких часов, прежде чем execution фактически покинет базу данных.

Могу ли я защитить отдельные важные executions от автоматического удаления?

Да, аннотированные executions, то есть те, у которых есть теги или оценка в редакторе n8n, согласно документации исключены из автоматической очистки. Это подходит для того, чтобы сохранить постоянно отслеживаемыми отдельные заметные случаи ошибок или эталонные запуски, не отключая глобальный pruning. Для основной массы рутинных executions автоматическое удаление тем не менее остаётся активным.

Нужно ли мне ещё что-то делать вручную с SQLite после pruning?

Да, поскольку SQLite не возвращает автоматически удалённое место на диске операционной системе, а продолжает использовать его внутренне для будущих executions. Тому, кто действительно хочет уменьшить используемое место на диске, следует, согласно документации n8n, либо установить DB_SQLITE_VACUUM_ON_STARTUP, либо время от времени вручную выполнять команду VACUUM. При PostgreSQL в качестве базы данных эта проблема, как правило, выражена слабее, поскольку управление хранилищем у неё устроено иначе.