--- title: "PostgreSQL для n8n: база, бэкапы, миграция и ошибки — Nodbot" source_url: "https://nodbot.ru/hosting/postgres/" canonical_url: "https://nodbot.ru/hosting/postgres/" language: "ru" content_type: "HostingGuide" section: "hosting" generated_at: "2026-05-30" word_count_source: 1041 --- # PostgreSQL для n8n: база, бэкапы, миграция и ошибки подключения ## AI summary Как использовать PostgreSQL для self-hosted n8n: env-переменные, Docker, pg_dump, восстановление, миграция с SQLite и типовые ошибки. ## Best used for Страница объясняет «PostgreSQL для n8n: база, бэкапы, миграция и ошибки — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Когда PostgreSQL обязателен - Минимальные переменные окружения - Права пользователя базы - Бэкап, который можно восстановить - Миграция с SQLite - Чистка execution data - Частые ошибки подключения - Порядок безопасного изменения ## Source outline Сохранить в мой план Открыть мой план # 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 — когда база упирается в лимиты. ## Официальные источники - n8n supported databases - n8n Postgres node ## Эксплуатационный контекст для 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 — открыть связанный материал для проверки контекста. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.