MySQL и PostgreSQL в n8n: SQL-запросы, upsert, отчёты и безопасность ¶

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

MySQL и PostgreSQL в n8n используют для трёх больших задач: читать данные из существующих систем, записывать события/заявки и строить устойчивые процессы с дедупликацией. SQL-ноды дают больше контроля, чем таблицы, но требуют аккуратности: ошибка в запросе может создать дубли, перезаписать данные или открыть доступ к лишним таблицам.

Когда брать MySQL, а когда PostgreSQL ¶

Базовый контракт таблицы событий ¶

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

CREATE TABLE inbound_events (
  id bigserial PRIMARY KEY,
  external_id text NOT NULL,
  source_system text NOT NULL,
  event_type text NOT NULL,
  payload jsonb,
  status text NOT NULL DEFAULT 'new',
  received_at timestamptz NOT NULL DEFAULT now(),
  UNIQUE (source_system, external_id)
);

Если внешний сервис повторно отправил webhook, уникальный ключ не даст создать дубль. Workflow сможет понять, что событие уже было, и вернуть корректный ответ.

Upsert вместо слепого insert ¶

Самая частая ошибка — делать insert на каждую заявку. Для webhook, оплат, лидов и писем лучше использовать upsert: создать, если записи нет; обновить, если она уже существует. В PostgreSQL это обычно делается через ON CONFLICT.

INSERT INTO inbound_events (external_id, source_system, event_type, payload)
VALUES ($1, $2, $3, $4::jsonb)
ON CONFLICT (source_system, external_id)
DO UPDATE SET payload = EXCLUDED.payload, received_at = now();

В n8n значения для запроса берите из уже нормализованных полей, а не из сырого тела webhook. Так меньше риск перепутать путь JSON.

SQL-запросы и пользовательский ввод ¶

Не собирайте SQL конкатенацией из пользовательских полей: телефона, email, текста формы, поискового запроса. Даже если workflow “внутренний”, данные могут прийти из webhook. Лучше использовать параметры, whitelists и заранее подготовленные поля. Если нужно динамически выбрать таблицу или колонку, ограничьте список допустимых значений через Switch или Code node.

Отчёты и выгрузки ¶

SQL-ноды удобны для ежедневных отчётов: заявки за день, оплаты по статусам, ошибки по типам, лиды без ответственного. Но отчётный запрос не должен блокировать production-таблицы. Для тяжёлых выборок используйте индексы, ограничение по дате, pagination и отдельные read-only credentials.

SELECT event_type, count(*) AS cnt
FROM inbound_events
WHERE received_at >= now() - interval '1 day'
GROUP BY event_type
ORDER BY cnt DESC;

Типовые ошибки подключения ¶

Как не сломать базу из n8n ¶

• Создавайте отдельные credentials для read-only и write workflow.
• Не используйте root/admin-пользователя БД.
• Проверяйте SQL на тестовой базе перед запуском.
• Для destructive-запросов добавляйте ручное подтверждение.
• Логируйте external_id и результат записи.
• Делайте backup перед массовым update.

Связанные материалы ¶

• Postgres node — отдельный справочник по ноде.
• PostgreSQL для self-hosted n8n — база самого n8n и бэкапы.
• Webhook idempotency — защита от повторных событий.
• Supabase и n8n — managed Postgres и API.