PostgreSQL для n8n: база, бэкапы, миграция и ошибки подключения ¶

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

В n8n слово PostgreSQL встречается в двух разных контекстах. Первый — база, где сам n8n хранит workflows, credentials metadata, users и executions. Второй — Postgres node внутри workflow, когда вы читаете или пишете данные бизнес-сценария. Эта статья про первый случай: как держать базу n8n на PostgreSQL и не потерять автоматизации при обновлении, падении VPS или переносе.

Не смешивайте базы

Не кладите таблицы клиентов и audit log в ту же схему, где живёт база самого n8n. Для бизнес-данных создайте отдельную базу или хотя бы отдельную схему и credential. Так проще делать бэкапы, ограничивать права и разбирать инциденты.

Когда PostgreSQL обязателен ¶

Ситуация	SQLite	PostgreSQL
Локальное обучение на ноутбуке	подходит	избыточен
VPS с рабочими интеграциями	рискованно	нормальный выбор
Много executions и webhooks	быстро становится слабым местом	проще обслуживать и бэкапить
Queue mode с workers	не тот сценарий	практически нужен
Перенос между серверами	можно, но неудобно	pg_dump/restore даёт предсказуемость

Минимальные переменные окружения ¶

В Docker Compose обычно задают такие значения:

DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_PORT=5432
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=change-this-password
N8N_ENCRYPTION_KEY=long-random-secret

N8N_ENCRYPTION_KEY храните отдельно от сервера. Если потерять ключ, старые credentials могут стать бесполезными даже при наличии дампа базы.

Права пользователя базы ¶

Не используйте суперпользователя PostgreSQL для приложения. Создайте отдельного пользователя n8n, отдельную базу n8n и выдайте права только на неё. Для бэкапов можно завести отдельного read-only/backup-пользователя, но в небольших установках чаще используют пользователя приложения и доступ к контейнеру.

Бэкап, который можно восстановить ¶

Snapshot VPS полезен, но он не заменяет дамп. Минимальный рабочий подход:

Раз в сутки делать pg_dump базы n8n.
Класть архив не только на этот же сервер, но и во внешнее хранилище.
Хранить несколько последних копий: например, 7 ежедневных и 4 еженедельных.
Раз в месяц прогонять восстановление на отдельной тестовой машине.

docker exec postgres pg_dump -U n8n -d n8n | gzip > n8n-$(date +%F).sql.gz

Если дамп ни разу не восстанавливали, это не бэкап, а надежда.

Миграция с SQLite ¶

Миграция требует аккуратности: остановить n8n, сделать копию текущей папки данных, подготовить PostgreSQL, перенести workflows/credentials штатным способом или через миграционные инструменты, затем проверить вход, credentials и несколько workflow. Не начинайте миграцию одновременно с обновлением версии n8n: сначала перенесите базу, затем отдельно обновляйтесь.

Чистка execution data ¶

PostgreSQL часто начинает расти не из-за workflows, а из-за executions: большие JSON, binary data, ошибки с повторными retry, webhooks с вложениями. Настройте retention, pruning и вынос файлов/attachments во внешнее хранилище. Для тяжёлых workflows не храните целиком HTML, PDF или изображения в execution data, если они нужны только один раз.

Частые ошибки подключения ¶

Ошибка	Что проверить	Как исправить
`ECONNREFUSED`	host, port, Docker network, жив ли контейнер	использовать имя сервиса `postgres` внутри compose-сети
`password authentication failed`	пароль в env и пароль пользователя в базе	синхронизировать secrets, пересоздать только если понятно, где volume
`database does not exist`	имя базы и init-скрипты	создать базу до запуска n8n или поправить env
после обновления пустой n8n	подключились к другой базе или volume	сравнить compose project, volume name и DB host
база быстро растёт	executions, binary data, retry loop	включить pruning и найти workflow-источник нагрузки

Порядок безопасного изменения ¶

Сделайте дамп базы и сохраните N8N_ENCRYPTION_KEY.
Остановите n8n, если меняете DB host, user или volume.
Запустите PostgreSQL и проверьте подключение отдельно.
Запустите n8n и откройте UI.
Проверьте один manual workflow, один production webhook и один credential.
Только после этого удаляйте старые контейнеры или volumes.

Операционный runbook для self-hosted ¶

Для темы «PostgreSQL для n8n» важно разделять настройку и эксплуатацию. Настройка отвечает на вопрос “запустилось ли”, эксплуатация — “сможем ли мы восстановиться, обновиться и расследовать инцидент без потери credentials и execution history”.

Перед изменениями проверьте бэкап базы, значение N8N_ENCRYPTION_KEY, состояние volume, логи web-процесса и worker-процесса. Главный риск — сделать неидемпотентную запись, поймать lock/timeout или незаметно нарушить схему данных.

Слой	Что зафиксировать	Зачем
Вход	запись из базы или SQL-операция с уникальным ключом, timestamp и результатом транзакции	позволяет повторить проблему без доступа к production-секретам
Контроль	query_duration, conflict_count, transaction_failures, row_count_delta, lock_wait	показывает деградацию раньше, чем пользователи начинают писать в поддержку
Безопасность	сделать неидемпотентную запись, поймать lock/timeout или незаметно нарушить схему данных	снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
Готовность	есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «PostgreSQL для n8n»	делает статью пригодной для runbook, а не только для чтения

Пример безопасного входного контракта ¶

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

Критерий готовности ¶

есть свежий backup базы и проверено значение N8N_ENCRYPTION_KEY
web, worker, queue и database используют согласованные переменные окружения
после изменения проверены логи, healthcheck и запуск критичных workflow
записан rollback-план с командами и ответственным

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

Queue mode — если нужно разделить UI и executions.
Backup/restore PostgreSQL — подробный runbook восстановления.
Миграция SQLite → PostgreSQL.
Too many connections — когда база упирается в лимиты.

Официальные источники ¶

Эксплуатационный контекст для self-hosted n8n

Страницу «PostgreSQL для n8n: база, бэкапы, миграция и ошибки подключения ¶» лучше читать как часть production-карты self-hosted n8n. Любое изменение инфраструктуры должно иметь владельца, план проверки, понятный rollback и наблюдаемость. Перед применением на VPS или в Kubernetes зафиксируйте текущую версию n8n, способ запуска, путь к данным, переменные окружения и место хранения backup.

Главный риск self-hosted установки — исправить один симптом и не заметить побочный эффект: потерю credentials, рост execution data, недоступность webhooks, ошибку reverse proxy или зависшие workers. Поэтому после изменений проверяйте не только UI, но и healthcheck, production webhook URL, очередь, базу данных, логи контейнера и успешный тестовый execution.

Ops-чеклист перед изменением

Сделайте backup базы, файлового хранилища и критичных env-переменных.
Проверьте, что есть понятный rollback и окно обслуживания.
Сравните логи до и после изменения: 4xx/5xx, latency, memory, disk, stalled jobs.
Проведите тест webhook, scheduled workflow и ручного запуска.

Для команды полезно хранить эту проверку рядом с runbook: что изменяли, кто подтвердил результат, какие метрики смотрели и какое условие считается неуспешным релизом.

Self-hosted n8n — открыть связанный материал для проверки контекста.
Логи и мониторинг — открыть связанный материал для проверки контекста.
Backup и update — открыть связанный материал для проверки контекста.
Launch checklist — открыть связанный материал для проверки контекста.