2026: как перенести n8n с SQLite на PostgreSQL и сохранить рабочие процессы?

Исходный SQLite уже обслуживает рабочие автоматизации, но непонятно, что именно переживёт смену базы.

Быстрое решение: не ограничивайтесь заменой переменных подключения на PostgreSQL. Сначала сделайте резервную копию и определите, что нужно сохранить, затем используйте подход, подтверждённый для текущей версии n8n, и отдельно проверьте рабочие процессы, credentials, пользователей и историю. Если история не нужна, оцените перенос только необходимых бизнес-данных; если нужна — сначала испытайте путь на копии, а не запускайте неподтверждённый скрипт.

Кому пригодится: независимым разработчикам, у которых самостоятельный экземпляр n8n уже выполняет постоянные задачи.
Руководителям небольших команд, которым важно сохранить доступы, принадлежность процессов и совместную работу.
Ответственным за обновление, которым нужно отделить перенос базы от перехода на n8n 2.x.

Последняя проверка — 31 октября 2026 года. Сверены официальные настройки баз данных n8n, документация CLI и материалы о переходе на версию 2.0. Конкретные шаги необходимо повторно проверить для установленной версии и выбранного способа развёртывания.

Сначала определите, что именно должно пережить перенос

Смена типа базы и миграция данных — разные задачи. Официальные настройки n8n описывают подключение SQLite и PostgreSQL, но изменение конфигурации подключения не означает, что старая база автоматически скопирована в новую. Если запустить экземпляр с параметрами PostgreSQL без переноса, новая база не станет копией старой.

Прежде чем выбирать процедуру, составьте перечень данных и ответьте на практический вопрос: что должно работать после переключения и что нужно уметь восстановить?

Не следует считать все перечисленные категории одинаковыми объектами миграции. CLI n8n документирует экспорт и импорт рабочих процессов и credentials, но это не доказывает, что стандартный импорт восстановит пользователей, отношения совместного доступа, историю запусков и связанные файлы. Для командной установки особенно важно проверить, как устроены проекты и доступ к ним: официальное описание совместного использования рабочих процессов помогает понять, какие связи нужно включить в сценарий приемки.

Выберите вариант по условиям

Используйте этот список как решение до подготовки целевой базы:

• Если экземпляр нужен для личных проб, нет требований к постоянной работе и SQLite не мешает текущей эксплуатации, оставьте базу на месте. Сделайте резервную копию и пересмотрите решение, когда появится конкретная причина менять её.
• Если n8n работает постоянно, а нужны только рабочие процессы и credentials, готовьте чистую PostgreSQL и план переноса именно этих данных. Не обещайте себе сохранение истории или пользователей, пока не проверен соответствующий путь.
• Если требуется сохранить командные права, пользователей или проекты, сначала испытайте миграцию на копии и проверьте данные под разными ролями. Если отношения не восстанавливаются подтверждённым способом, отложите переключение.
• Если обязательно нужна история выполнений, не начинайте перенос по обычному сценарию импорта рабочих процессов. Найдите и проверьте подход, подходящий текущей версии и типу истории; при отсутствии подтверждённого пути оставьте исходную систему доступной и перенесите запуск на отдельное окно.
• Если одновременно планируется обновление n8n 2.x, сначала проверьте миграцию базы на исходной версии либо на отдельно подготовленной копии, а обновление принимайте как самостоятельное изменение.

Это решение особенно важно для n8n, который перешёл от личного тестирования к производственной автоматизации: «в новой базе видны процессы» — не то же самое, что «команда восстановила привычный доступ и может безопасно выполнять задачи».

Для одиночного владельца подготовьте перенос без потери доступа

Для самостоятельной установки главная опасность — получить импортированные записи, которые нельзя полноценно использовать. У credentials содержимое зашифровано; поэтому при переносе нужно сохранить исходный ключ шифрования и проверить его применимость в целевой среде. Сам факт, что credential отображается в интерфейсе, не заменяет пробный вызов с этим доступом.

Порядок подготовки:

1. Зафиксируйте исходное состояние. Запишите версию n8n, способ запуска, используемые переменные, подключённые хранилища и фактическое расположение файлов. Не меняйте одновременно образ, параметры базы и структуру хранения.
2. Остановите изменения. На время подготовки не редактируйте рабочие процессы и credentials, иначе экспорт и исходная база могут отражать разные состояния.
3. Сделайте резервную копию. Сохраните SQLite и связанные с экземпляром данные отдельно от рабочей системы. Если копируются файлы, убедитесь, что копия пригодна для восстановления, а не просто присутствует в каталоге.
4. Сохраните секреты и ключ шифрования. Храните их контролируемым способом, не добавляйте в публичный репозиторий и не отправляйте в обычный лог. Проверьте, какие параметры нужны именно вашему способу запуска.
5. Подготовьте целевую PostgreSQL. Проверьте, что n8n подключается к нужной базе с требуемыми правами, а не к случайно созданной пустой базе или другой среде.
6. Проверьте процедуру на копии. Официальная документация CLI описывает операции экспорта и импорта. Сверьте синтаксис команд для установленной версии и сначала выполните их на тестовом экземпляре.
7. Проведите приёмку до переключения трафика. Импортируйте нужные объекты, проверьте открытие процессов, тестовый вызов credentials, расписание и Webhook. Только после этого согласуйте переключение.

В документации CLI описаны команды для экспорта и импорта рабочих процессов и credentials. Встречающиеся в инструкциях команды n8n export:workflow, n8n export:credentials, n8n import:workflow и n8n import:credentials следует сверить с актуальными параметрами и способом запуска конкретного экземпляра по руководству n8n CLI. Не вставляйте команду из чужого примера без проверки: имена файлов, права доступа и параметры импорта должны соответствовать вашей среде.

Для небольшой команды проверьте пользователей и видимость

Командная система требует больше, чем рабочие процессы и credentials. Сотрудник может видеть процесс благодаря настройкам совместного доступа, проекту или принадлежности пользователя. Если перенести только объекты автоматизации, интерфейс может выглядеть заполненным, но распределение доступа окажется другим.

До миграции сформируйте контрольный перечень:

• какие пользователи должны входить в систему;
• какие процессы видит каждый участник;
• кому разрешено изменять процессы и credentials;
• какие общие ресурсы используются несколькими процессами;
• кто отвечает за восстановление при неудачном переключении.

На тестовой копии проверьте не только наличие записей, но и их связь. Войдите под разными учётными записями, сравните список доступных рабочих процессов с исходной системой и проверьте, что credentials доступны тем автоматизациям и участникам, которым они нужны. Отдельно испытайте создание и изменение процесса, если эти действия входят в рабочий сценарий команды.

Не делайте вывод о полной сохранности прав только по успешному импорту: он подтверждает лишь результат конкретной операции. Если для вашей версии и конфигурации не найден официальный путь переноса пользовательских отношений, зафиксируйте это ограничение до планирования переключения. Для команды это может стать основанием сначала пересобрать доступы по проверяемому списку, а не объявлять перенос завершённым.

Для истории и файлов установите отдельный сценарий проверки

История выполнений и бинарные данные не равны рабочим процессам или credentials. Экспорт процессов не следует считать экспортом истории. Если прежние запуски нужны для аудита или расследования ошибок, заранее определите, какие записи и связанные данные должны оставаться доступными, и проверьте выбранный метод на копии.

Официальная документация n8n отдельно описывает настройки хранения и очистки истории выполнений. Это полезно для планирования будущего хранения, но само по себе не является подтверждением, что история будет перенесена при смене базы. Зафиксируйте, какие данные должны сохраниться, сколько их нужно оставить и как команда проверит их полноту после переноса.

Похожая осторожность нужна для файлов. В зависимости от конфигурации и вида данных бинарное содержимое может храниться не так, как сведения о рабочем процессе. Сверьте фактический режим работы с документацией по бинарным данным, включите нужные файлы в копию и испытайте восстановление. Не считайте базу PostgreSQL резервной копией: смена СУБД не создаёт автоматически отдельную копию данных, план восстановления или высокую доступность.

Скрипты сообщества и ручное преобразование записей можно рассматривать только как неподтверждённый вариант. До применения проверьте на копии структуру данных, полноту результата, восстановление и требуемое дисковое пространство. Частный успешный пример не гарантирует совместимость с другой версией, набором расширений или способом хранения.

Разведите перенос базы и переход на n8n 2.x

Одновременное изменение версии и базы усложняет поиск причины сбоя: после неудачного запуска будет непонятно, повлияли ли схема данных, новые требования версии, изменение конфигурации или несовместимость рабочего процесса. Поэтому миграцию базы и обновление версии лучше принимать раздельно.

Перед обновлением прочитайте официальный отчёт о миграции на 2.0 и описание несовместимых изменений. Эти материалы — отправная точка для проверки версии, а не основание переносить чужой сценарий без тестирования.

План разделите на два самостоятельных этапа:

• Этап переноса базы: исходная версия, резервная копия, перенос нужных категорий данных, проверка доступа и запуск тестовых автоматизаций.
• Этап обновления: анализ изменений целевой версии, отдельная копия для испытания, проверка поведения процессов и сохранение понятного пути возврата.

После первого этапа зафиксируйте результат и только затем обновляйте n8n. Если обновление уже выполнено, не считайте предыдущие инструкции автоматически применимыми: сверяйте миграционный отчёт и настройки базы именно для текущей версии.

Примите результат по ролям и проверьте эксплуатационные условия

Перед переключением используйте чек-лист; каждый пункт должен иметь ответственного и понятный результат проверки.

• [ ] Резервная копия исходной базы и связанных файлов создана и проверена восстановлением на отдельной среде.
• [ ] Сохранены необходимые секреты и проверена работа ключа шифрования.
• [ ] Рабочие процессы открываются, запускаются вручную и остаются в ожидаемом состоянии.
• [ ] Credentials проходят тестовый вызов; в журналах нет ошибки расшифровки или авторизации.
• [ ] Расписание и Webhook проверены способом, соответствующим реальным точкам запуска.
• [ ] Пользователи видят требуемые процессы и не получают лишнего доступа.
• [ ] История и бинарные данные проверены отдельно, если они входят в обязательный объём переноса.
• [ ] Назначено условие возврата: какие признаки означают остановку переключения и восстановление исходного экземпляра.

Затем оцените место для базы не по предположению «PostgreSQL займёт столько же», а по измерениям своего экземпляра. Зафиксируйте текущий размер базы и каталогов с файлами, динамику их роста, настройки хранения выполнений и размер создаваемых резервных копий. Если история будет храниться дольше или файловые данные останутся на том же сервере, учитывайте эти объёмы отдельно. Сначала измерьте фактический рост, затем сопоставьте его с доступным хранилищем и своим интервалом резервного копирования.

Для самостоятельного хостинга важно также понимать, что смена СУБД не снимает обязанность самостоятельно организовать копирование и восстановление. До выбора размещения проверьте доступный объём диска, подходящую систему и периодичность оплаты в актуальных конфигурациях XFP Cloud. При планировании аренды заранее сверьте применимые условия обслуживания XFP Cloud, а ответственность за создание и хранение резервных копий оцените отдельно. Само наличие сервера не означает, что резервная копия хранится отдельно от него.

Ответы на частые вопросы

Как безопасно перенести n8n с SQLite на PostgreSQL?

Сначала зафиксируйте версию n8n, остановите изменения в исходном экземпляре и сохраните резервную копию вместе с ключом шифрования. Затем определите, нужны ли история запусков, пользователи и бинарные данные, а не только рабочие процессы и credentials. Проверьте поддерживаемый текущей версией путь в официальной документации и выполните перенос на копии. Переключение параметров подключения само по себе старую базу не переносит.

Останутся ли рабочие процессы и credentials после смены базы n8n?

Они не появятся в новой базе автоматически. Официальная документация CLI описывает экспорт и импорт рабочих процессов и credentials, но перед импортом нужно проверить, как выбранные параметры обрабатывают существующие идентификаторы: импорт может затронуть совпадающие объекты. Для зашифрованных credentials сохраните и проверьте исходный ключ шифрования, иначе наличие записей в базе ещё не означает, что их удастся использовать.

Нужно ли переносить историю выполнений n8n?

Решение зависит от требований к разбору сбоев, аудиту и внутренним процедурам хранения. Если прежняя история не нужна, разумно отдельно оценить перенос только необходимых рабочих данных, вместо того чтобы считать её обязательной частью импорта. Если история должна сохраниться, не полагайтесь на обычный экспорт рабочих процессов и credentials: сначала подтвердите применимый к вашей версии способ и проверьте полноту записей на копии.

Что проверить перед обновлением n8n 2.x вместе с переносом базы?

Не объединяйте оба изменения в одну непроверяемую операцию. Сверьте исходную и целевую версии с официальными материалами о переходе на 2.x и отчётом миграции, затем испытайте миграцию базы отдельно. После неё проверьте запуск, доступ пользователей и нужные данные; обновление версии принимайте отдельным этапом. До завершения обеих проверок сохраняйте исходную базу и определите условия возврата.

Если текущая среда — общая виртуальная машина, сначала выясните, насколько предсказуемы доступные ресурсы и можно ли контролировать размещение базы и резервных копий: соседняя нагрузка, ограничения на дисковую конфигурацию и раздельное хранение копий могут осложнить эксплуатацию, если эти условия действительно есть у вашего тарифа. Для n8n и PostgreSQL, которым нужны отдельные ресурсы и понятное размещение, аренда выделенного AMD-сервера XFP Cloud может оказаться подходящим вариантом. Сверьте актуальные условия и доступное хранилище в конфигурациях, а затем решите, стоит ли размещать оба сервиса на одной машине.

Частые вопросы

1. Как безопасно перенести n8n с SQLite на PostgreSQL?

   Сначала зафиксируйте версию n8n, остановите изменения в исходном экземпляре и сохраните резервную копию вместе с ключом шифрования. Затем определите, нужны ли история запусков, пользователи и бинарные данные, а не только рабочие процессы и credentials. Проверьте поддерживаемый текущей версией путь в официальной документации и выполните перенос на копии. Переключение параметров подключения само по себе старую базу не переносит.

2. Останутся ли рабочие процессы и credentials после смены базы n8n?

   Они не появятся в новой базе автоматически. Официальная документация CLI описывает экспорт и импорт рабочих процессов и credentials, но перед импортом нужно проверить, как выбранные параметры обрабатывают существующие идентификаторы: импорт может затронуть совпадающие объекты. Для зашифрованных credentials сохраните и проверьте исходный ключ шифрования, иначе наличие записей в базе ещё не означает, что их удастся использовать.

3. Нужно ли переносить историю выполнений n8n?

   Решение зависит от требований к разбору сбоев, аудиту и внутренним процедурам хранения. Если прежняя история не нужна, разумно отдельно оценить перенос только необходимых рабочих данных, вместо того чтобы считать её обязательной частью импорта. Если история должна сохраниться, не полагайтесь на обычный экспорт рабочих процессов и credentials: сначала подтвердите применимый к вашей версии способ и проверьте полноту записей на копии.

4. Что проверить перед обновлением n8n 2.x вместе с переносом базы?

   Не объединяйте оба изменения в одну непроверяемую операцию. Сверьте исходную и целевую версии с официальными материалами о переходе на 2.x и отчётом миграции, затем испытайте миграцию базы отдельно. После неё проверьте запуск, доступ пользователей и нужные данные; обновление версии принимайте отдельным этапом. До завершения обеих проверок сохраняйте исходную базу и определите условия возврата.