Supabase и n8n: связка для автоматизаций

Supabase закрывает хранение и доступ, n8n - процессы вокруг данных. Связка популярна именно потому, что каждый инструмент делает то, что второй делает плохо.

Доступ из воркфлоу

Два способа, и выбор зависит от задачи.

Через HTTP-слой. Обращение к таблицам обычными запросами с ключом. Просто, не требует открывать базу наружу, подходит для точечных операций: получить запись, создать, обновить.

Напрямую к PostgreSQL. Обычное подключение к базе из воркфлоу. Даёт полный SQL: агрегаты, соединения, массовые операции. Незаменимо для отчётов, где считать надо на стороне базы, а не тянуть строки в воркфлоу.

Правило безопасности одно и важное: служебный ключ и доступ к базе живут в креденшелах n8n, а не в теле запроса. Экспорт воркфлоу и историю выполнений видит любой, у кого есть доступ к интерфейсу - см. работу с API в n8n.

Второе: служебный ключ обходит политики доступа. Воркфлоу с ним видит все данные, поэтому ограничивать его надо на уровне того, что делает сам воркфлоу - см. авторизацию и RLS.

Вебхуки из базы

Более интересный сценарий: автоматизация запускается изменением данных.

Схема: триггер в базе срабатывает при вставке или обновлении строки и вызывает вебхук n8n, передавая данные.

Что это даёт: новая заявка появилась в базе - воркфлоу отправил уведомление, создал задачу в трекере и написал в чат. Приложение при этом ничего об этом не знает и не должно знать.

Что обязательно учесть:

Идемпотентность. Триггер может сработать повторно, а вебхук - продублироваться. Без проверки по идентификатору записи вы получите два письма и два заказа - см. идемпотентные пайплайны.

Скорость. Триггер выполняется в транзакции. Ждать ответа от n8n внутри неё нельзя: воркфлоу должен вызываться так, чтобы не задерживать запись.

Защита эндпоинта. Вебхук n8n - публичный адрес, и его найдут. Секрет проверяется первой нодой - см. вебхуки в n8n.

Отказ n8n. Если воркфлоу недоступен, вызов пропадёт. Для важных событий надёжнее записывать их в очередь-таблицу, которую n8n разбирает по расписанию: тогда сбой означает задержку, а не потерю.

Типовые сценарии

• Уведомления. Новая запись - сообщение в чат или на почту.
• Обогащение данных. Появился клиент - воркфлоу дособрал информацию из внешних источников и обновил запись.
• Синхронизация с CRM. В обе стороны, по отметке времени изменения.
• Отчёты по расписанию. n8n читает базу, считает и отправляет - см. примеры воркфлоу.
• Очистка и обслуживание. Удаление устаревшего, пересчёт агрегатов.
• Обработка загруженных файлов. Файл появился в хранилище - воркфлоу обработал.

Границы связки

Где эта схема перестаёт работать:

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

Высокая частота событий. Тысячи изменений в минуту через вебхуки - плохая идея. Здесь нужен пакетный разбор по расписанию.

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

Секреты и права. Воркфлоу со служебным ключом обходит все ограничения. Это удобно и означает, что доступ к интерфейсу n8n надо ограничивать как доступ к базе.

Общая картина - гид по Supabase и гид по n8n.