--- title: "MySQL и PostgreSQL в n8n: SQL-запросы, upsert — Nodbot" source_url: "https://nodbot.ru/integrations/mysql/" canonical_url: "https://nodbot.ru/integrations/mysql/" language: "ru" content_type: "IntegrationGuide" section: "integrations" generated_at: "2026-05-30" word_count_source: 979 --- # MySQL и PostgreSQL в n8n: SQL-запросы, upsert, отчёты и безопасность ## AI summary Как работать с MySQL и PostgreSQL в n8n: SQL query, insert/update, upsert, отчёты, credentials, защита от дублей, транзакции и ошибки подключения. ## Best used for Страница объясняет «MySQL и PostgreSQL в n8n: SQL-запросы, upsert — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Когда брать MySQL, а когда PostgreSQL - Базовый контракт таблицы событий - Upsert вместо слепого insert - SQL-запросы и пользовательский ввод - Отчёты и выгрузки - Типовые ошибки подключения - Как не сломать базу из n8n - Практический контракт интеграции ## Source outline # MySQL и PostgreSQL в n8n: SQL-запросы, upsert, отчёты и безопасность Обновлено: 2026-05-29 MySQL и PostgreSQL в n8n используют для трёх больших задач: читать данные из существующих систем, записывать события/заявки и строить устойчивые процессы с дедупликацией. SQL-ноды дают больше контроля, чем таблицы, но требуют аккуратности: ошибка в запросе может создать дубли, перезаписать данные или открыть доступ к лишним таблицам. Не начинайте с полного доступа Для n8n создавайте отдельного пользователя БД с минимальными правами. Workflow для отчётов не должен иметь право удалять строки, а workflow для записи лидов не должен видеть служебные таблицы. ## Когда брать MySQL, а когда PostgreSQL - Ситуация | Что чаще выбрать | Комментарий - legacy-сайт или CMS уже на MySQL | MySQL | n8n подключается к существующей базе - новая production-автоматизация | PostgreSQL | удобнее для JSONB, отчётов, idempotency и очередей - лог событий webhook | PostgreSQL | хорошо хранить raw event и normalized payload - простые чтения каталога | MySQL или Postgres | зависит от текущей инфраструктуры - RAG/vector сценарии | PostgreSQL/pgvector или Qdrant | не путать с обычной БД n8n ## Базовый контракт таблицы событий Для 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; ``` ## Типовые ошибки подключения - Симптом | Причина | Что проверить - ECONNREFUSED | БД недоступна с контейнера n8n | host, port, docker network, firewall - permission denied | у пользователя нет прав | GRANT только на нужные таблицы - SSL error | сервер требует SSL или наоборот | настройки credentials и провайдера - duplicate key | insert без upsert | ON CONFLICT или предварительная проверка - слишком долго выполняется | нет индекса или большой диапазон | EXPLAIN, индекс, фильтр по дате ## Как не сломать базу из n8n - Создавайте отдельные credentials для read-only и write workflow. - Не используйте root/admin-пользователя БД. - Проверяйте SQL на тестовой базе перед запуском. - Для destructive-запросов добавляйте ручное подтверждение. - Логируйте external_id и результат записи. - Делайте backup перед массовым update. ## Практический контракт интеграции Интеграция «MySQL и PostgreSQL в n8n» должна начинаться с контракта данных: кто источник, какой внешний ID считается главным, какие поля можно перезаписывать и что делать при повторной доставке. Без этого n8n быстро превращается в слой случайного mapping между сервисами. Минимально опишите запись из базы или SQL-операция с уникальным ключом, timestamp и результатом транзакции. Главный риск — сделать неидемпотентную запись, поймать lock/timeout или незаметно нарушить схему данных. - Слой | Что зафиксировать | Зачем - Вход | запись из базы или SQL-операция с уникальным ключом, timestamp и результатом транзакции | позволяет повторить проблему без доступа к production-секретам - Контроль | query_duration, conflict_count, transaction_failures, row_count_delta, lock_wait | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | сделать неидемпотентную запись, поймать lock/timeout или незаметно нарушить схему данных | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «MySQL и PostgreSQL в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "operation": "upsert", "dedupe_key": "source_system:external_id", "expected_rows": 1, "on_conflict": "update_changed_fields_only", "audit": {"workflow_id": "...", "execution_id": "..."} } ``` ### Критерий готовности - описан основной external_id и политика upsert/dedupe - credentials имеют минимально нужные права и понятного владельца - известно, какие поля можно менять автоматически, а какие только после review - есть обработка 401/403, 429, 5xx и изменения схемы payload ## Связанные материалы - Postgres node — отдельный справочник по ноде. - PostgreSQL для self-hosted n8n — база самого n8n и бэкапы. - Webhook idempotency — защита от повторных событий. - Supabase и n8n — managed Postgres и API. ## Практическое применение страницы Материал «MySQL и PostgreSQL в n8n: SQL-запросы, upsert, отчёты и безопасность» лучше использовать как точку входа в рабочий маршрут, а не как изолированную справку. Перед внедрением выберите конкретный процесс, источник данных, владельца и ожидаемый результат. Это помогает быстро понять, какая страница базы нужна дальше: рецепт, диагностика, интеграция, нода или production-playbook. Для любой автоматизации в n8n полезно заранее описать входной item, обязательные поля, внешние сервисы, write-действия и способ отката. Если эти детали не зафиксированы, даже простой workflow может стать неуправляемым: дублирует заявки, теряет часть items, отправляет уведомления не тем людям или ломается при изменении формата API. ### Минимальный чеклист - Определите, что является успешным результатом и кто его подтверждает. - Проверьте happy path, пустой вход, повтор события и сбой внешнего сервиса. - Добавьте логирование execution id, source, external id и статуса без секретов. - Свяжите страницу с ближайшим рецептом, ошибкой или playbook. ### Что открыть дальше - Интеграции — открыть связанный материал для проверки контекста. - Рецепты — открыть связанный материал для проверки контекста. - Диагностика — открыть связанный материал для проверки контекста. - OAuth checklist — открыть связанный материал для проверки контекста. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) - [Сравнения](/compare/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.