База данных n8n: когда нужен отдельный сервис, а когда хватит SQLite

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

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

Роль базы данных в n8n

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

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

История выполнений также размещается в базе данных, если для конкретного типа данных не настроено иное поведение. Она полезна для поиска ошибок, анализа времени выполнения и проверки результатов, но при большом количестве запусков быстро увеличивает объём хранилища. Рабочая конфигурация должна заранее определять, сколько истории необходимо сохранять и какие данные можно удалять автоматически.

Важно отделять базу данных n8n от веб-сервера, reverse proxy и хранилища бинарных объектов. HTTPS для пользовательского интерфейса защищает соединение браузера с n8n, а защищённое соединение между n8n и внешней базой является отдельной настройкой. Эти уровни безопасности не заменяют друг друга.

SQLite для небольших установок

SQLite используется как простой вариант для локального или небольшого развёртывания. База представляет собой файл, поэтому для запуска не требуется отдельный сервер PostgreSQL или другой СУБД. Такой подход удобен для обучения, личных проектов, тестирования узлов и автоматизаций с небольшой нагрузкой.

Проверить подходящий вариант можно на странице Beget.

Главное преимущество SQLite — минимальное количество компонентов. Администратору не нужно создавать отдельную базу, настраивать сетевой доступ и управлять пользователями СУБД. При этом файл базы должен находиться на постоянном диске. Если n8n запущен в контейнере без подключённого volume, удаление контейнера может привести к потере данных.

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

SQLite подходит, когда:

• n8n используется одним человеком или небольшой командой;
• количество запусков невелико;
• достаточно одного экземпляра приложения;
• база хранится на надёжном постоянном диске;
• настроено регулярное копирование и проверка восстановления.

Если автоматизации стали критичными для бизнеса, появились постоянные параллельные запуски или потребовалось горизонтальное масштабирование, стоит заранее перейти на серверную СУБД. Не следует ждать, пока файл SQLite станет узким местом или перестанет помещаться в удобную схему резервного копирования.

PostgreSQL и внешняя база для production

PostgreSQL часто выбирают для постоянно работающих инсталляций n8n. Внешняя база лучше подходит для нескольких пользователей, большого числа workflow и регулярной истории выполнений. Она предоставляет отдельный контур доступа, инструменты резервирования, журналирование, мониторинг и возможность использовать управляемый сервис.

При таком размещении n8n и PostgreSQL могут находиться на одной внутренней сети. Это уменьшает задержки и позволяет закрыть базу от общего интернета. Если используется облачная СУБД, необходимо проверить правила доступа, разрешённые IP-адреса, политику TLS и способ хранения секретов. Открывать порт базы для всего интернета обычно не требуется.

Серверную базу целесообразно выбирать, если:

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

Для queue mode особенно важно заранее проверить требования конкретной версии n8n. Распределённая обработка предполагает согласованную работу нескольких компонентов, поэтому локальный файл SQLite не должен использоваться как общий ресурс между контейнерами. Помимо базы данных, в такой архитектуре обычно требуется отдельный брокер очереди, а конфигурация всех процессов должна быть одинаковой.

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

Перед настройкой откройте Beget и сверьте актуальные условия.

Настройка подключения и безопасность

Для подключения к PostgreSQL n8n использует параметры окружения. Названия переменных и доступные опции зависят от версии, поэтому перед изменением конфигурации нужно сверяться с официальной документацией. В типичной схеме задаются тип базы, адрес сервера, порт, имя базы, пользователь и пароль. Секреты лучше передавать через менеджер секретов или защищённые переменные окружения, а не записывать в репозиторий и Docker-образ.

Минимальный порядок настройки выглядит так:

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

Ключ шифрования следует хранить отдельно от публичных файлов проекта, но включать его в защищённый план резервного восстановления. Его нельзя публиковать в логах, сообщениях об ошибках, скриншотах и переменных, доступных всем пользователям CI/CD.

Соединение с внешней базой должно проходить по защищённому каналу, если этого требует инфраструктура или политика безопасности. Сертификат для TLS соединения с PostgreSQL — это не то же самое, что сертификат HTTPS для домена n8n. В первом случае защищается канал между приложением и базой, во втором — доступ пользователя к веб-интерфейсу и API.

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

Резервное копирование и контроль роста

Надёжная резервная копия n8n должна включать несколько компонентов:

• дамп базы данных или снимок управляемой СУБД;
• постоянный ключ шифрования;
• настройки подключения и версию развернутого n8n;
• локальное файловое хранилище, если оно используется;
• объектное хранилище и его параметры, если бинарные данные вынесены отдельно;
• описание переменных окружения без раскрытия самих секретов.

Копия должна храниться в другом месте, чем рабочая база. Если база и её единственная копия находятся на одном диске, отказ диска или ошибка оператора уничтожит оба экземпляра. Для критичных систем полезно определить допустимые значения RPO и RTO: сколько данных можно потерять и за какое время сервис должен быть восстановлен.

История выполнений требует отдельной политики хранения. Полное сохранение всех успешных запусков редко необходимо на протяжении нескольких лет. Обычно оставляют более длительную историю для ошибок и ограниченный срок для успешных выполнений. n8n предоставляет переменные окружения для автоматической очистки execution data; их конкретные значения нужно подбирать по нагрузке и требованиям аудита.

Когда требования понятны, перейдите в Beget и проверьте выбранный вариант.

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

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

Практический план миграции

Перед миграцией с SQLite на PostgreSQL необходимо определить окно работ и временно остановить изменения в workflow. Если во время копирования продолжаются записи, часть запусков может попасть в промежуточное состояние. Для небольшого инстанса безопаснее остановить n8n, создать резервную копию файла SQLite и только затем выполнять перенос.

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

Проверка после миграции должна включать:

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

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

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

Что почитать дальше

• AI-шлюз для агентов: контроль расходов и безопасности данных
• Какие данные сохранить после запуска сайта: карточка проекта
• Amazon закрывает MTurk: 5 альтернатив для разметки данных в 2026
• GPT-5.6 Sol удаляет файлы: риски и защита данных бизнеса
• Когда подписка на сервис дешевле собственной разработки: разбор для небольшой строительной компании

Обложка вдохновлена гравюрой Кацусики Хокусая «Большая волна в Канагаве» (около 1831). Посмотреть оригинал в коллекции Метрополитен-музея.