Перейти до вмісту

ADR-0010: Supabase — не як платформа; pgvector на RDS, не Supabase

Статус: accepted · 2026-06-06 · власник @Vladbandurin

Періодично виникає питання «а може перейти на Supabase?». Supabase — це інтегрований BaaS-bundle: managed Postgres + PostgREST (auto-REST) + GoTrue (Auth) + Storage (S3-wrapper) + Realtime (WS-over-WAL) + Edge Functions (Deno) + pgvector + Studio. Його ціннісна пропозиція — прибрати бекенд.

Стан Abitly/Studsearch, що визначає рішення:

  • Кожен pillar Supabase уже є AWS-native і в Terraform: Postgres → RDS 17.9 (studsearch-prod, shared, schema isolation), Storage → S3, черги → Valkey/BullMQ, функції → ECS Fargate. Джерело правди — cloud-infrastructure.
  • Архітектура backend-centric, не BaaS: NestJS · TypeORM · BullMQ · Swagger · Prometheus + MCP API для внутрішніх агентів. Бізнес-логіка живе в коді, не в RLS-політиках.
  • Auth — single source of truth у NestJS, зчеплений з Monobank, Tutor-сервісом і Telegram HMAC initData. Auth-картка явно виключає Supabase Auth.
  • Дані неповнолітніх + GDPR: увесь естейт у власному AWS-акаунті 952854879948, eu-central-1; резидентність і consent — ADR-grade (ADR-0002, ADR-0007, ADR-0009).
  • Realtime як продуктова потреба не задокументована (канал — Telegram).

Supabase не приймається як платформа. Лишаємось на AWS-native + Terraform. Зокрема:

  1. Core Auth, платежі та shared-RDS — поза межами. GoTrue не моделює temp-токени й Telegram-initData-логін; заміна root-of-trust переписує coupling платежів/бота й перевипускає токени всім — високий ризик заради нульової вимоги, всупереч auth-ADR.
  2. Для abitly-recsys вектор-пошук = pgvector як extension на власній RDS (наявній або виділеній recsys-RDS), не Supabase. Supabase-pgvector — той самий extension; embeddings лишаються co-located з реляційним каталогом для дешевого hybrid SQL+vector ранжування, без нового мережевого хопа й без нового processor.
  3. Допустимо лише à la carte по краях (additive, ізольовано, без адопшну платформи):
    • Supabase Studio як зручний read-only дашборд на shared RDS (краще за psql/TablePlus при дебагу SPoF).
    • Self-host / EU-pinned Supabase як швидкий бекенд для справді greenfield, одноразового під-продукту (квіз-мікросайт, lead-capture), що має власні дані й не залежить від core-JWT, платежів чи shared-схеми. Щойно потрібна автентифікація проти наявних юзерів — сценарій відпадає.
КритерійСтатус-кво (AWS-native)Supabase CloudSelf-host Supabase
Fit-to-stack✅ найкращий❌ PostgREST/RLS воює з логікою❌ той самий mismatch у VPC
Migration cost/risk✅ нуль❌ високий (auth/платежі)❌ високий + 6 контейнерів
Cost✅ найнижчий (1 shared RDS)❌ per-project compute, over поза Spend Cap❌ дублюєш ECS-сервіси
EU/GDPR residency✅ Terraform-pinned, свій акаунт❌ лише контрактна; US-вендор → CLOUD Act🟡 свій eu-central-1, без нового processor
Operational surface✅ найменший🟡 +2nd control plane❌ GoTrue/PostgREST/Realtime/Kong/Storage
Lock-in✅ низький (portable PG/S3/TF)❌ high (cloud-only PITR/replicas/branching)🟡 OSS, але всі ops на тобі
  • (+) Нуль нових вендорів/processor-ів, нуль нових DPA; резидентність лишається закодованою в Terraform, а не контрактною.
  • (+) Єдиний CloudTrail/SSM/Terraform/consent-ledger audit-периметр; повне володіння 72-год breach-clock (GDPR Art. 33).
  • (+) Жодного дублювання шести вже наявних AWS-примітивів; auth-ADR не порушено.
  • (−) Не отримуємо «з коробки» Studio/branching/PITR-UX Supabase — прийнятно (наявні TypeORM-міграції + AWS-tooling покривають потребу).
  • Перегляд: якщо колись з’явиться задокументована потреба в in-app realtime або справді ізольований greenfield-напрямок — повернутись до п.3 (à la carte), не до платформної міграції.

Розглянуті альтернативи

Section titled “Розглянуті альтернативи”
  • Supabase Cloud як платформа. Найвищий compliance-ризик: новий US-domiciled processor (CLOUD Act навіть для EU-регіону — це residency, не sovereignty), резидентність падає до контрактної, діра в audit-периметрі, розділене incident-response ownership. SOC2 Type 2 / ISO 27001 / HIPAA-BAA є, але гейтнуті на Team+ (pricing), а compute-overаге не покривається Spend Cap (compute docs). Відхилено — і так виключено auth-ADR.
  • Self-host Supabase замість статус-кво. Зберігає резидентність і no-new-processor, але додає 6+ stateful/proxy-контейнерів (GoTrue/PostgREST/Realtime/Kong/Storage/Studio) під патч/моніторинг/security заради спроможностей, які вже є. Self-host також втрачає managed-ops (backups/PITR, replicas, branching, logs) — self-hosting docs. Відхилено для core; допустимо лише для greenfield-краю (п.3).
  • Supabase лише як managed-Postgres. Викидає ~80% цінності bundle, але імпортує весь processor-/audit-/cost-оверхед Cloud. Відхилено.