Supabase и n8n: как связать базу, API, Auth и RAG в один надёжный workflow ¶

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

Короткий ответ ¶

Supabase в n8n можно использовать как обычную базу/Backend-as-a-Service и как AI/RAG-слой через Supabase Vector Store. Production-интеграция требует чёткого разделения ключей, RLS, service role, таблиц состояния, idempotency, validation, audit log и контроля доступа к персональным данным. Для n8n Supabase node подходит для операций со строками, Supabase Vector Store — для RAG и AI Agent, а сложные операции можно вынести в Postgres/HTTP Request или Edge Function.

Когда Supabase стоит подключать к n8n ¶

Supabase удобно использовать, когда n8n должен работать с данными приложения: заявки, пользователи, подписки, события, контент, статусы обработки, RAG-документы, AI memory, internal tools. Он сочетает Postgres, API, Auth и storage-подход, поэтому часто становится мостом между low-code workflow и реальным продуктом.

Типовые сценарии: форма сайта пишет lead в Supabase, n8n обогащает и отправляет в CRM; приложение создаёт событие, n8n отправляет письмо; support ticket попадает в таблицу, AI классифицирует и обновляет статус; база знаний хранится в Supabase Vector Store и используется AI Agent.

Supabase node и Supabase Vector Store ¶

В n8n Supabase node работает с обычными строками: создавать, получать, удалять и обрабатывать записи. Supabase Vector Store — отдельный AI/RAG-инструмент: его можно использовать как regular node для insert/retrieve документов, подключать как tool к AI Agent, использовать через retriever или QA tool. Не смешивайте эти роли.

Если вам нужно обновить статус заказа — используйте Supabase/Postgres operations. Если нужно отвечать на вопросы по документам — используйте Supabase Vector Store с embeddings, chunks и metadata. Если нужна сложная бизнес-логика — лучше сделать SQL function/Edge Function или отдельный backend endpoint и вызывать его из n8n.

Credentials, RLS и service role ¶

Главный риск Supabase-интеграций — неправильный ключ. Public anon key предназначен для клиентских сценариев с RLS, service role key даёт расширенные права и должен храниться только на сервере. В n8n credentials можно использовать API key, но важно понимать, какие права он даёт.

Production-правило: отдельный Supabase credential для n8n, минимально нужные права, отдельные таблицы для automation state, никакого service role в browser, exports или Notion. Если workflow обрабатывает user data, RLS и backend policy должны быть согласованы. n8n как серверный процесс может обходить часть клиентских ограничений, если вы используете мощный ключ, поэтому ответственность за проверку прав переносится на workflow.

Схема таблиц для автоматизации ¶

Не пишите все данные в одну таблицу logs. Разделите: business tables, automation_events, sync_checkpoints, ai_reviews, rag_sources, error_queue. Это делает replay и аудит возможными.

Пример таблицы событий:

create table automation_events (
  id bigserial primary key,
  source text not null,
  external_id text not null,
  status text not null,
  payload jsonb not null,
  result jsonb,
  error text,
  created_at timestamptz default now(),
  updated_at timestamptz default now(),
  unique (source, external_id)
);

Такой unique key защищает от дублей при повторной доставке webhook или ручном replay.

Idempotency и upsert ¶

Supabase часто используется как state layer для интеграций. Если n8n получает событие из Stripe, Telegram, сайта или CRM, сначала создайте/обновите запись в таблице событий. Только после этого вызывайте внешние действия. При повторном запуске workflow должен увидеть существующий source + external_id и решить, пропустить или продолжить с безопасной точки.

Для customer records используйте upsert по внешнему id, email_norm или user_id. Не полагайтесь на “поиск похожей строки” без unique constraint: два параллельных executions могут создать дубль.

Supabase Auth и пользовательский контекст ¶

Если workflow действует от имени пользователя, нужно сохранить user_id, tenant_id, роль и разрешённые действия. Не доверяйте user_id из входящего webhook без проверки. Для private data добавьте lookup: кто пользователь, к какому tenant относится, разрешён ли доступ к объекту. Если n8n использует service role, именно workflow должен проверить tenant boundary.

Для multi-tenant SaaS заведите обязательные поля tenant_id, actor_user_id, correlation_id. Все записи audit log должны содержать tenant_id. Для RAG metadata тоже должен быть tenant_id, иначе один клиент может получить ответ по документам другого.

Supabase Vector Store и RAG ¶

Для RAG в Supabase продумайте collection/table, chunk_id, source_id, tenant_id, document_type, status, updated_at, source_url, access_level. Не индексируйте черновики, приватные документы и удалённые страницы без tombstone-логики. При refresh сравнивайте hash текста: если документ не изменился, не пересоздавайте embeddings.

Схема ingestion: взять документы → нормализовать → chunk → добавить metadata → embeddings → Supabase Vector Store insert. Схема ответа: chat/query → metadata filter → retrieve top-k → AI Agent/QA chain → source-aware answer → audit. Если RAG даёт плохие ответы, проверяйте не только модель, но и chunks, metadata filters и свежесть индекса.

Storage, файлы и вложения ¶

Если Supabase Storage используется рядом с n8n, сохраняйте не только URL файла, но и owner, content type, hash, size, scan status, retention policy. Не отправляйте вложения в AI до проверки размера и типа. Для PDF/документов добавьте этап extract text и статус parsed, failed, needs_review.

Если файл содержит PII, workflow должен маскировать данные до LLM или использовать внутренний контур обработки. Для публичных ссылок задавайте срок жизни и не храните бессрочные signed URLs в логах.

Monitoring и troubleshooting ¶

Типовые ошибки: 401 из-за ключа, 403 из-за RLS, 404/empty result из-за неправильной таблицы/схемы, duplicate key при повторном событии, timeout на тяжёлом запросе, неверная timezone, metadata filter не возвращает RAG-документы. Для каждой ошибки логируйте table, operation, external id, tenant_id, response code и correlation_id.

Добавьте dashboards: входящие события, успешные upsert, duplicate skips, failed RAG ingestion, average latency, review queue, vector search empty results. Supabase-интеграция без наблюдаемости быстро превращается в “почему в приложении не обновился статус?”.

Production-чеклист ¶

Проверьте credentials, RLS, service role, tenant boundary, unique constraints, indexes, backups, schema migrations, idempotency table, retry policy, error queue, PII redaction, RAG metadata filters, тест удаления/обновления документов, staging-проект и rollback. Для AI-сценариев добавьте eval dataset и тесты доступа: пользователь A не должен получить документы пользователя B.

FAQ ¶

Чем Supabase node отличается от Supabase Vector Store? ¶

Supabase node работает со строками и обычными операциями приложения. Supabase Vector Store используется для embeddings, retrieval и RAG/AI Agent сценариев.

Можно ли использовать service role key в n8n? ¶

Можно только как серверный секрет в credentials, но нужно минимизировать права, не раскрывать ключ и самому проверять tenant/user access.

Почему Supabase возвращает пустой результат? ¶

Частые причины: RLS, неправильный ключ, неверная таблица/схема, фильтр tenant_id или тип значения.

Как избежать дублей? ¶

Использовать external_id, unique constraints, upsert и таблицу automation_events с idempotency key.

Можно ли строить RAG на Supabase? ¶

Да, через Supabase Vector Store, но нужны chunks, metadata, фильтры доступа, refresh policy и evaluation dataset.