---
title: "Миграция SQLite → Postgres для n8n — Nodbot"
source_url: "https://nodbot.ru/hosting/migrate-sqlite-to-postgres/"
canonical_url: "https://nodbot.ru/hosting/migrate-sqlite-to-postgres/"
language: "ru"
content_type: "HostingGuide"
section: "hosting"
generated_at: "2026-05-30"
word_count_source: 683
---

# Миграция SQLite → Postgres для n8n

## AI summary

Практический план миграции n8n с SQLite на Postgres: что сохранить до переноса, как подготовить новую базу, какие ENV изменить, как проверить credentials, executions и webhook после переключения.

## Best used for

Материал помогает администратору n8n разобраться с темой «Миграция SQLite → Postgres для n8n», выполнить production-проверки, не смешивать соседние задачи и сохранить понятный rollback.

## Key topics

- Когда нужна миграция с SQLite на Postgres
- Что зафиксировать до переноса
- Пошаговый план миграции
- Пример runbook-записи
- Проверка после переключения
- Типичные ошибки при миграции
- Критерий готовности
- Что читать дальше

## Source outline

# Миграция n8n с SQLite на Postgres без потери workflows [¶](#migraci-n8n-s-sqlite-na-postgres "Permanent link")

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

Сохранить в мой план[Открыть мой план](/my-plan/)

**Эта страница про один конкретный переход: действующий self-hosted n8n уже работает на SQLite, но инстанс нужно перевести на Postgres так, чтобы не потерять workflows, credentials, webhook URL и историю важных запусков.**

## Когда нужна миграция с SQLite на Postgres [¶](#kogda-nuzhna-migraciya-s-sqlite-na-postgres "Permanent link")

SQLite подходит для локальных экспериментов, небольших демо и одиночного администратора, но в production быстро становится ограничением. Признаки, что пора переходить на Postgres: несколько пользователей одновременно работают в UI, растёт история executions, появляются регулярные webhook-нагрузки, планируется queue mode с Redis, а обновления n8n уже нельзя делать без понятного backup и restore.

Миграцию не стоит делать “по пути” вместе с обновлением версии n8n, сменой домена, переездом на новый сервер и включением workers. Каждое изменение должно иметь свой rollback. Иначе при ошибке будет непонятно, что сломало систему: база, ENV, reverse proxy, новая версия образа или credentials.

## Что зафиксировать до переноса [¶](#chto-zafiksirovat-do-perenosa "Permanent link")

| Артефакт | Зачем нужен | Где проверить |
| --- | --- | --- |
| текущий 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 станут бесполезными. Это самый частый скрытый риск при переносе базы.

## Пошаговый план миграции [¶](#poshagovyy-plan-migracii "Permanent link")

1. **Остановите n8n.** Нельзя переносить активную SQLite-базу, пока workflow продолжают писать executions. Зафиксируйте maintenance window и уведомите владельцев автоматизаций.
2. **Сделайте холодный backup.** Сохраните SQLite-файл, .env, compose-файл, версию образа, volume с binary data и runbook отката. Backup должен лежать вне сервера, на котором выполняется миграция.
3. **Поднимите Postgres отдельно от n8n.** Создайте базу, пользователя и пароль. Проверьте подключение обычным клиентом до изменения n8n ENV.
4. **Перенесите данные согласованным способом.** Используйте поддерживаемый экспорт/импорт или миграционный скрипт вашей сборки. Не копируйте таблицы вручную, если не понимаете схему и миграции n8n.
5. **Обновите ENV только для базы.** Меняйте DB\_TYPE, DB\_POSTGRESDB\_\* и связанные параметры, но не меняйте одновременно WEBHOOK\_URL, encryption key, домен, proxy и версию образа.
6. **Запустите n8n и выполните smoke-test.** Проверьте UI, список workflows, открытие credentials, manual execution, production webhook и один schedule trigger.

## Пример runbook-записи [¶](#primer-runbook-zapisi "Permanent link")

```
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”, а процедуру, которую можно повторить в реальном инциденте.

## Проверка после переключения [¶](#proverka-posle-pereklyucheniya "Permanent link")

* UI открывается по старому публичному адресу, а canonical host не изменился случайно.
* Workflows отображаются с прежними именами, тегами, статусом active/inactive и владельцами.
* Credentials открываются без ошибки расшифровки и проходят тест подключения.
* Webhook trigger принимает внешний запрос, а ответ не зависит от старого SQLite volume.
* Manual execution и schedule trigger создают записи уже в Postgres.
* Логи не показывают повторяющиеся database migration errors, permission denied или connection refused.

## Типичные ошибки при миграции [¶](#tipichnye-oshibki-pri-migracii "Permanent link")

* переносить базу после одновременного upgrade n8n и потом искать причину в трёх местах;
* забыть N8N\_ENCRYPTION\_KEY и получить workflows без рабочих credentials;
* оставить старый SQLite volume подключенным и думать, что n8n уже пишет в Postgres;
* не проверить timezone и pruning, из-за чего история executions начинает расти иначе;
* проверить только вход в UI, но не webhook, schedule, binary data и external API credentials.

## Критерий готовности [¶](#kriteriy-gotovnosti-hosting-migrate-sqlite-to-postgres "Permanent link")

Миграция завершена только тогда, когда есть новый Postgres backup, сохранённый encryption key, успешный smoke-test критичных workflows, понятный rollback на SQLite-снимок и запись в runbook. Пока проверен только запуск контейнера, перенос нельзя считать безопасным.

## Что читать дальше [¶](#chto-chitat-dalshe "Permanent link")

После переноса настройте [Postgres backup и restore](/hosting/postgres-backup-restore/), пересмотрите [переменные окружения n8n](/hosting/environment-variables/) и только потом планируйте [масштабирование queue mode](/hosting/scaling/). Для общей процедуры обновлений используйте [upgrade checklist](/hosting/upgrade-checklist/).