Миграция n8n с SQLite на Postgres без потери workflows ¶
Обновлено: 2026-05-30
Эта страница про один конкретный переход: действующий self-hosted n8n уже работает на SQLite, но инстанс нужно перевести на Postgres так, чтобы не потерять workflows, credentials, webhook URL и историю важных запусков.
Когда нужна миграция с SQLite на Postgres ¶
SQLite подходит для локальных экспериментов, небольших демо и одиночного администратора, но в production быстро становится ограничением. Признаки, что пора переходить на Postgres: несколько пользователей одновременно работают в UI, растёт история executions, появляются регулярные webhook-нагрузки, планируется queue mode с Redis, а обновления n8n уже нельзя делать без понятного backup и restore.
Миграцию не стоит делать “по пути” вместе с обновлением версии n8n, сменой домена, переездом на новый сервер и включением workers. Каждое изменение должно иметь свой rollback. Иначе при ошибке будет непонятно, что сломало систему: база, ENV, reverse proxy, новая версия образа или credentials.
Что зафиксировать до переноса ¶
| Артефакт | Зачем нужен | Где проверить |
|---|---|---|
| текущий SQLite-файл | исходная база для экспорта и аварийного возврата | volume или путь внутри compose |
| N8N_ENCRYPTION_KEY | расшифровывает credentials после переноса | .env, secret store, runbook |
| версия n8n | снижает риск несовместимости схемы | docker image tag или UI |
| WEBHOOK_URL | проверяет, что внешние сервисы попадут в тот же публичный адрес | ENV и reverse proxy |
| критичные workflows | задаёт smoke-test после миграции | список владельцев процессов |
Отдельно сохраните список credentials, которые должны открыться после миграции. Если encryption key потерян или отличается, workflows могут отображаться, но реальные подключения к API станут бесполезными. Это самый частый скрытый риск при переносе базы.
Пошаговый план миграции ¶
- Остановите n8n. Нельзя переносить активную SQLite-базу, пока workflow продолжают писать executions. Зафиксируйте maintenance window и уведомите владельцев автоматизаций.
- Сделайте холодный backup. Сохраните SQLite-файл, .env, compose-файл, версию образа, volume с binary data и runbook отката. Backup должен лежать вне сервера, на котором выполняется миграция.
- Поднимите Postgres отдельно от n8n. Создайте базу, пользователя и пароль. Проверьте подключение обычным клиентом до изменения n8n ENV.
- Перенесите данные согласованным способом. Используйте поддерживаемый экспорт/импорт или миграционный скрипт вашей сборки. Не копируйте таблицы вручную, если не понимаете схему и миграции n8n.
- Обновите ENV только для базы. Меняйте DB_TYPE, DB_POSTGRESDB_* и связанные параметры, но не меняйте одновременно WEBHOOK_URL, encryption key, домен, proxy и версию образа.
- Запустите n8n и выполните smoke-test. Проверьте UI, список workflows, открытие credentials, manual execution, production webhook и один schedule trigger.
Пример runbook-записи ¶
migration: sqlite_to_postgres
service: n8n-production
before_version: n8n:1.x.y
database_before: sqlite volume snapshot
database_after: postgres://n8n@postgres:5432/n8n
encryption_key_source: secret manager / n8n/prod/encryption_key
rollback: stop n8n, restore sqlite volume, restore previous DB env, start previous image
smoke_test: UI + credential open + webhook + manual execution + schedule triggerХорошая запись не содержит пароль в открытом виде, но показывает, где он хранится и кто имеет право его получить. Это важно для SEO-пользователя страницы тоже: он ищет не абстрактное “настройте Postgres”, а процедуру, которую можно повторить в реальном инциденте.
Проверка после переключения ¶
- UI открывается по старому публичному адресу, а canonical host не изменился случайно.
- Workflows отображаются с прежними именами, тегами, статусом active/inactive и владельцами.
- Credentials открываются без ошибки расшифровки и проходят тест подключения.
- Webhook trigger принимает внешний запрос, а ответ не зависит от старого SQLite volume.
- Manual execution и schedule trigger создают записи уже в Postgres.
- Логи не показывают повторяющиеся database migration errors, permission denied или connection refused.
Типичные ошибки при миграции ¶
- переносить базу после одновременного upgrade n8n и потом искать причину в трёх местах;
- забыть N8N_ENCRYPTION_KEY и получить workflows без рабочих credentials;
- оставить старый SQLite volume подключенным и думать, что n8n уже пишет в Postgres;
- не проверить timezone и pruning, из-за чего история executions начинает расти иначе;
- проверить только вход в UI, но не webhook, schedule, binary data и external API credentials.
Критерий готовности ¶
Миграция завершена только тогда, когда есть новый Postgres backup, сохранённый encryption key, успешный smoke-test критичных workflows, понятный rollback на SQLite-снимок и запись в runbook. Пока проверен только запуск контейнера, перенос нельзя считать безопасным.
Что читать дальше ¶
После переноса настройте Postgres backup и restore, пересмотрите переменные окружения n8n и только потом планируйте масштабирование queue mode. Для общей процедуры обновлений используйте upgrade checklist.