SQLite или PostgreSQL: когда пора переходить

По умолчанию n8n запускается с SQLite, файловой базой данных без собственного серверного процесса, которая не требует отдельной установки. Для тестовых экземпляров, отдельных автоматизаций и для начала работы этого достаточно. Но как только вы запускаете несколько параллельных выполнений workflow, используете режим очереди или хотите использовать несколько main-инстансов, n8n в собственной документации прямо рекомендует PostgreSQL версии 13 или выше. Правильный момент для перехода зависит не столько от фиксированного числа пользователей, сколько от трёх факторов: числа параллельных выполнений, планируемой архитектуры и того, как часто в логах уже появляются ошибки блокировки. Актуально на: июль 2026 года.

Признаки того, что SQLite достигает своих пределов

В сообществе n8n снова и снова возникает одна и та же ошибка: SQLITE_BUSY: database is locked. Причина кроется в архитектуре SQLite, которая допускает только один одновременный доступ на запись на файл. Если несколько workflow выполняются параллельно или вы открываете редактор во время активных выполнений, доступы на запись к одному и тому же файлу сталкиваются. Кратковременно помогает режим WAL (Write-Ahead Logging) с тайм-аутом занятости не менее 5000 миллисекунд, это снижает частоту ошибок. Однако лежащее в основе ограничение на одного пишущего клиента при этом не устраняется и надёжно возвращается при росте нагрузки.

Пороговые значения, которые называет сам n8n

В документации n8n не указывает фиксированное число выполнений в день в качестве точки перехода, а связывает этот предел с конкретными архитектурными решениями.

• Планируется режим очереди: Для продуктивной работы в режиме очереди n8n прямо указывает, что режим выполнения queue с базой данных SQLite не рекомендуется. Как только процессы worker начинают параллельно писать в одну и ту же базу данных, требуется Postgres.
• Несколько main-инстансов (Multi-Main): Для высокой доступности с несколькими main-процессами n8n прямо требует подключения к Postgres и Redis; SQLite для этого не предусмотрен.
• Конкуренция worker'ов: Значение concurrency на одного worker по умолчанию составляет 10, n8n рекомендует не менее 5. При большом числе worker'ов с низкой конкуренцией, согласно документации, возникает риск исчерпания соединений с базой данных, ситуация, с которой однофайловая база данных без настоящего пула соединений структурно справляется плохо.
• Референсное значение из бенчмарка: В официальных тестах производительности отдельный инстанс с бэкендом Postgres достигает до 220 выполнений workflow в секунду. Это не предел SQLite, но показывает, для какого класса нагрузки рассчитан Postgres в n8n.
• Сигнал из n8n Cloud: Даже в собственном облачном продукте Postgres остаётся зарезервирован для тарифов Enterprise Scaling, все более младшие уровни работают на SQLite. Это примерно отражает, с какого момента сам n8n считает переход необходимым.

Шаги миграции с SQLite на PostgreSQL

Переход выполняется через экспорт и импорт, а не через автоматическое преобразование файла базы данных.

• Подготовить PostgreSQL: Развернуть Postgres версии 13 или новее, создать отдельную базу данных и выделенного пользователя с полными правами на неё.
• Экспортировать workflow и credentials: Сделать резервную копию через CLI с помощью n8n export:workflow --all --output=backup/ и n8n export:credentials --all --decrypted --output=backup/. Расшифрованную резервную копию credentials после этого сразу нужно поместить в защищённое, недоступное публично место.
• Изменить переменные окружения: Установить DB_TYPE в значение postgresdb, а также настроить хост, порт, имя базы данных, пользователя, пароль и, при необходимости, схему через соответствующие переменные DB_POSTGRESDB.
• Запустить n8n на пустой базе данных Postgres: n8n сам создаёт необходимую схему при первом запуске, вручную создавать таблицы не требуется.
• Восстановить данные: С помощью n8n import:workflow --separate --input=backup/ и n8n import:credentials --separate --input=backup/ восстановить сохранённые состояния и затем выборочно протестировать workflow.

Трудозатраты и ограничения перехода

Переход не выполняется в один клик, а представляет собой небольшое окно обслуживания: во время экспорта, перенастройки и импорта n8n ненадолго останавливается, а подробные истории выполнения не переносятся автоматически стандартным способом. Для небольших инсталляций с малым числом workflow трудозатраты умеренные, для выросших инстансов со множеством активных автоматизаций стоит заранее протестировать на staging-инстансе. Тот, кто не хочет единолично нести ответственность за этот шаг во время работающей системы, может также привлечь внешнее сопровождение, например в рамках консультации по n8n по фиксированной цене.

Часто задаваемые вопросы о SQLite и PostgreSQL в n8n

С какого числа выполнений в день нужно переходить на PostgreSQL?

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

Могу ли я просто продолжать использовать SQLite, увеличив только busy timeout?

Для небольших инстансов с малым уровнем параллелизма да, это может заметно снизить количество ошибок блокировки. Но как только вы переходите к режиму очереди или Multi-Main, по данным n8n этой настройки уже недостаточно.

Теряются ли данные при миграции?

Стандартный путь через экспорт и импорт надёжно переносит workflow и credentials. Полные истории выполнения автоматически в него не включаются, тому, кому они нужны, следует отдельно проверить это перед миграцией.

Обязательно ли мне нужен режим очереди для PostgreSQL?

Нет. Вы можете использовать PostgreSQL и в режиме single-main без режима очереди, например, чтобы избежать ошибок блокировки. Режим очереди и Multi-Main являются отдельными уровнями расширения, которые дополнительно требуют Redis.

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