n8n и PostgreSQL: первый запрос без изменения данных
Подключи Postgres к n8n и получи учебную сводку обращений: параметры подключения, SQL и проверка результата.
Связка n8n и PostgreSQL полезна для регулярных сводок: получить обращения, посчитать статусы, подготовить данные для отчёта. Первый шаг — проверить соединение и результат чтения. Для упражнения используем строки прямо внутри запроса, поэтому создавать таблицу и менять данные в базе не потребуется.
1. Получи отдельное подключение для чтения
Нужны доступный сервер PostgreSQL, база и разрешённая учётная запись. Попроси администратора предоставить подключение для учебного чтения; не используй административный аккаунт только ради первого запуска. Если сервера нет, сначала подготовь его с ответственным за инфраструктуру: сам узел n8n базу не создаёт.
По справке credentials n8n потребуются Host, Database, User, Password, Port и параметры SSL. Введи реальные значения в хранилище credentials n8n, а не в текст SQL. Параметры шифрования возьми из инструкции владельца базы. Ошибку сертификата стоит разбирать отдельно, а не постоянно отключать проверку.
Важно, откуда подключается n8n. localhost внутри облачного сервиса или контейнера не означает твой ноутбук. Уточни адрес, который видит именно сервер n8n. Пароль и полный адрес подключения не помещай в скриншоты или описание публичного workflow.
2. Собери минимальный процесс
Создай workflow Manual Trigger → Postgres. Выбери подготовленные credentials и операцию Execute Query. Документация Postgres node описывает её как выполнение SQL-запроса.
Для первой проверки вставь:
SELECT 1 AS connection_ok;Выполни узел. Ожидается одна строка с connection_ok = 1. Этот результат подтверждает соединение и выполнение запроса. Он ещё не подтверждает доступ к конкретной рабочей таблице или правильность будущей бизнес-метрики.
Если соединение не установлено, посмотри сообщение ошибки. Тайм-аут указывает на необходимость проверить сетевой путь; отказ в аутентификации — credentials; запрет доступа — выданные права. Не меняй сразу пароль, SQL и сетевые настройки: иначе трудно понять, что исправило проблему.
3. Получи сводку на четырёх учебных строках
Теперь замени запрос на этот:
WITH tickets(id, status) AS (
VALUES
(101, 'open'),
(102, 'closed'),
(103, 'open'),
(104, 'waiting')
)
SELECT status, COUNT(*)::integer AS ticket_count
FROM tickets
GROUP BY status
ORDER BY status;Конструкция VALUES в PostgreSQL задаёт набор строк внутри запроса. Здесь tickets — учебный набор, не созданная таблица на диске. Запрос не содержит операций записи.
Ожидаемый результат можно проверить вручную:
| status | ticket_count |
|---|---|
| closed | 1 |
| open | 2 |
| waiting | 1 |
Сумма — четыре обращения. Наличие трёх выходных строк не означает три обращения: каждая строка теперь представляет группу статуса. Это частая причина неправильных сводок при передаче данных дальше.
4. Проверь смысл результата до подключения ИИ
Посмотри выход Postgres в n8n: должны присутствовать три группы и два поля. Если следующий узел запускается отдельно для каждой группы, он получит только часть сводки. Для общего отчёта сначала реши, как объединить все три результата; подробнее — в сопоставлении данных между узлами.
Если позднее передаёшь сводку языковой модели, задай ограничение:
Опиши только переданные количества по статусам.
Укажи общее число обращений и число открытых.
Не называй открытые обращения просроченными:
сроков и времени создания в данных нет.
Не вычисляй конверсию, SLA и динамику без дополнительных данных.Ориентир — четыре обращения, два открытых. Утверждение «половина нарушила SLA» неверно: статус open не равен просрочке. Проверка арифметики не заменяет определения показателя.
Моя рекомендация: сначала согласовать, что означает одна строка результата. После группировки это часто уже не клиент и не заявка, а категория — и ошибки начинаются именно здесь.
5. Перейди к рабочей таблице отдельным шагом
Попроси владельца данных согласовать таблицу или представление, поля, фильтры и определение метрики. Начни с ограниченного чтения и сравни результат с известным отчётом. Для динамических значений используй Query Parameters узла, а не склейку SQL из пользовательского текста.
Агенту доступ к базе нужен только после отдельной проверки границ — смотри чтение базы ИИ-агентом. Такие интеграции разбираем на курсе по ИИ-агентам. SQL проверен редакционно по документации и ручным подсчётом; соединение с PostgreSQL и запуск n8n здесь не выполнялись.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗