Supabase vs Firebase vs Neon для SaaS-бэкендов

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

Если нужен краткий ответ: для большинства B2B SaaS с отчетностью и сложными связями берите Postgres-ветку — Supabase или Neon. Firebase уместен для мобильных/реалтайм‑продуктов с простыми документами и толерантностью к вендор-локу. Supabase — «всё-в-одном» Postgres с Auth/Storage/Realtime и быстрым стартом. Neon — серверлесс Postgres с ветвлениями и автоскейлом, но без «склеек» (Auth/Storage нужно собирать из внешних сервисов). Часто выигрывает гибрид: Neon + Next.js/NestJS + Auth0/Clerk + S3/Cloudflare, а realtime — через pg_notify/WebSocket.

Что вы реально строите в SaaS

У типичного SaaS‑бэкенда повторяются одни и те же требования:

• Мульти‑тенантность: изоляция данных клиентов (RLS/префиксы/шейдинг).
• Отчеты и аналитика: сложные JOIN, агрегации, ad-hoc запросы BI.
• Транзакции и целостность: счета, биллинг, инвойсы — либо атомарно, либо никак.
• Реалтайм: уведомления, presence, live-таблицы (но не всегда hard‑RT).
• Интеграции: Stripe, Slack, вебхуки в обе стороны.
• Безопасность и соответствие: GDPR/DSGVO, аудиты, бэкапы, PITR.
• Стоимость: предсказуемый TCO без сюрпризов на чтениях/записях.

Если у вас B2B-учетные данные, отчеты, события аудита и «сметы», SQL чаще выигрывает. Если у вас мобильная соц‑фича с чатами и нет требований к ad-hoc BI, документы и триггеры Firebase будут быстрее в разработке.

Платформы и их модель данных

Supabase

• База: Postgres полностью управляемый, SQL/ACID, триггеры, расширения (pgvector, PostGIS и т.д.).
• API: PostgREST (CRUD поверх схем) + Edge Functions (Deno) + Realtime (через лог репликации).
• Безопасность: Row Level Security (RLS) на уровне БД.
• Доп. сервисы: Auth (email/OAuth, JWT), Storage (S3‑подобный), метрики, SQL редактор.
• Плюс: быстро собрать «полный» бэкенд из коробки, меньше клея.
• Минус: вы на rails Supabase (квоты на realtime, тайм‑ауты Edge Functions, DevOps — в пределах платформы).

Firebase (Firestore + экосистема)

• База: Firestore — документо‑ориентированная, квазиреляционные паттерны требуют денормализации.
• API: SDK на всех платформах, мощные офлайн‑кэши и слушатели изменений.
• Функции: Cloud Functions/Cloud Run, а также Extensions.
• Безопасность: правила доступа (Security Rules).
• Плюс: молниеносный старт для мобильных и realtime‑приложений, пуш‑слушатели «из коробки».
• Минус: сложные запросы/отчеты больно, индексы руками, стоимость растет на количестве чтений; SQL-аналитика — через экспорт/BigQuery.

Neon

• База: серверлесс Postgres, разделение хранения и вычислений, автоскейл до нуля, ветвления БД как git‑branch.
• API: нативный Postgres через драйверы/ORM (Prisma, Drizzle), pgBouncer, Logical Replication.
• Безопасность: на уровне Postgres и вашей инфраструктуры (RLS, политики).
• Плюс: «чистый» Postgres с современным серверлесс‑управлением, дешевые песочницы/превью по веткам.
• Минус: нет встроенных Auth/Storage/Realtime, нужно собирать стек, учитывать холодные старты compute.

Архитектурно: Supabase — бандл «Postgres + периферия». Firebase — платформа событий и документ‑хранилища. Neon — фундамент SQL без «удочек», зато с гибкостью для продвинутых архитектур.

Сравнение по ключевым критериям

Если ваши продуктовые KPI опираются на ad‑hoc SQL‑отчеты и cross‑tenant аналитику с денормализацией — NoSQL обернется дополнительными ETL и BigQuery счетами. Если же основной сценарий — синхронизация простых документов между мобильными клиентами, Firestore иногда закрывает 80% задач за недели.

Типовые архитектуры для SaaS

1) Supabase‑first: быстрый мономодуль

• Next.js (App Router) + Supabase Auth (JWT) + RLS для мульти‑тенантности.
• PostgREST для CRUD, Edge Functions для бэкенд‑логики, Storage для загрузок.
• Stripe вебхуки в Edge Function, события в таблицу billing_events.

SQL‑фрагмент: мульти‑тенантный доступ с RLS и безопасной функцией для чтения только своих записей.

-- Таблица с привязкой к tenant_id
create table if not exists invoices (
  id uuid primary key default gen_random_uuid(),
  tenant_id uuid not null,
  amount_cents integer not null,
  status text not null check (status in ('draft','sent','paid')),
  created_at timestamptz not null default now()
);

-- Включаем RLS и политику на пользователя (tenant в JWT)
alter table invoices enable row level security;

create policy tenant_isolation on invoices
  for all using (current_setting('request.jwt.claims', true)::jsonb ->> 'tenant_id' = tenant_id::text);

-- Безопасная функция чтения, учитывающая RLS
create or replace function api_my_invoices()
returns setof invoices language sql security definer as $$
  select * from invoices
  where tenant_id = (current_setting('request.jwt.claims', true)::jsonb ->> 'tenant_id')::uuid
  order by created_at desc
$$;

Плюс: минимальный клей, сильная безопасность на уровне БД. Минус: сложная доменная логика внутри Edge Functions и SQL требует дисциплины.

2) Firebase‑first: мобильный реалтайм

• Клиенты (iOS/Android/Web) напрямую говорят с Firestore.
• Cloud Functions для проверок платежей и агрегаций, Cloud Storage для файлов.
• Денормализация для быстрых экранов (например, «текущие балансы» кешируются отдельными документами).
• Поиск — через Algolia.

TypeScript‑функция валидации входящих вебхуков Stripe и записи в Firestore:

import * as functions from 'firebase-functions';
import Stripe from 'stripe';
import { getFirestore } from 'firebase-admin/firestore';
import * as admin from 'firebase-admin';

admin.initializeApp();
const db = getFirestore();
const stripe = new Stripe(process.env.STRIPE_SECRET!, { apiVersion: '2023-10-16' });

export const stripeWebhook = functions.https.onRequest(async (req, res) => {
  const sig = req.headers['stripe-signature'] as string;
  let event;
  try {
    event = stripe.webhooks.constructEvent(req.rawBody, sig, process.env.STRIPE_WEBHOOK_SECRET!);
  } catch (err) {
    res.status(400).send(`Webhook Error: ${(err as Error).message}`);
    return;
  }

  if (event.type === 'invoice.payment_succeeded') {
    const invoice = event.data.object as any;
    await db.collection('tenants').doc(invoice.metadata.tenantId)
      .collection('billing_events').doc(invoice.id).set({
        amount: invoice.amount_paid,
        status: 'paid',
        createdAt: admin.firestore.FieldValue.serverTimestamp()
      });
  }

  res.json({ received: true });
});

Плюс: из коробки офлайн/реалтайм, быстрое прототипирование. Минус: стоимость на чтениях и сложные отчеты.

3) Neon + «собранный» прод‑стек

• API: NestJS/Express или tRPC в Next.js.
• БД: Neon Postgres + Prisma/Drizzle.
• Auth: Clerk/Auth0/Кастом через JWT в Gateway.
• Кэш: Redis/Upstash.
• Файлы: S3/Cloudflare R2.
• Внешние: Stripe вебхуки, Slack боты.
• CDN/WAF: Cloudflare, плюс аккуратность с кэшированием и запросами в URL.

Подключение к Neon через Drizzle ORM в TypeScript:

import { drizzle } from 'drizzle-orm/node-postgres';
import pg from 'pg';

const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL, max: 10 });
export const db = drizzle(pool);

// Пример запроса
// await db.select().from(invoices).where(eq(invoices.tenantId, tenantId));

Плюс: контроль на всех слоях, чистый SQL, минимальный вендор‑лок. Минус: больше ответственности (логирование, миграции, алерты). Здесь как раз выручают «уроки продакшена» уровня JVM/Netty, см. наш разбор production‑практик — подходы схожи и для Node/Nest.

Что ломается в продакшене

• Supabase Realtime: при большом числе подписок нужно внимательно проектировать каналы и фильтры; чрезмерный чати‑подобный паттерн может упереться в квоты. Edge Functions — следите за временем выполнения, внешние API‑вызовы складываются и «съедают» тайм‑лимит. Хитрость: тяжелое — в очереди (e.g. Cloud Tasks/Temporal), а в Edge — только оркестрация.
• Firebase Firestore: стоимость за «чтения» часто взлетает из‑за неявных повторных запросов (слушатели на экранах, которые пользователь редко смотрит). Денормализация порождает каскадные апдейты; без аккуратных Cloud Functions возникают гонки. Композитные индексы нужны заранее — иначе прод получит 500/задержки из‑за «нет индекса» и авто‑сгенеренной ссылки на их создание. Security Rules с ростом логики становятся нечитаемыми тест‑пирамидками — инвестируйте в симуляторы и контрактные тесты.
• Neon: холодные старты compute после простоя — иногда неожиданные пики латентности на первый запрос. Лечится прогревом или минимальным scale‑to‑one. Ветвления БД прекрасны, но с миграциями легко создать дрейф схемы между ветками — автоматизируйте миграции (Prisma/Flyway) + «хард‑стопы» на CI, если миграция не применена. Также помните о лимитах долгих транзакций в серверлесс‑режиме — держите транзакции короткими.
• Общие грабли: вебхуки Stripe/Slack без ретраев и идемпотентности; отсутствие DLQ для событий; проблемы с PITR/бэкапами (проверяйте восстановление регулярно). Мульти‑тенантность на уровне приложений без RLS легко приводит к «утечке» данных при ошибке в WHERE — RLS в Postgres спасает.

Маленькая радость: 80% инцидентов исчезают после внедрения нормальных алертов на p95 латентности и очередей ретраев; 20% остаются, чтобы мы не заскучали.

Стоимость и ROI

• Старт: все три платформы имеют «фри/стартер» уровни, позволяющие MVP без счета за облака.
• Малый прод (до нескольких тысяч MAU): Supabase/Neon часто укладываются в десятки/пару сотен долларов в месяц при разумных ресурсах; Firebase может быть еще дешевле, если грамотно проектировать запросы.
• Рост: Firestore начинает «кусаться» на чтениях/индексах; Supabase/Neon масштабируются по ресурсам (CPU/RAM/коннекты), но вы контролируете расходы.
• Скрытые статьи: сетевой egress из Storage, BigQuery для отчетов (в случае Firebase), нагрузочные пики на Realtime (Supabase) и прогрев compute (Neon).
• Командные затраты: с Firebase быстрее стартует фронт/мобайл, но аналитическая команда позже попросит SQL; миграция документов в реляционную схему — месяцы. С Neon вы платите временем инженеров на склейку сервисов, но экономите на долгосрочном вендор‑локе. Supabase — компромиссный середнячок.

Дорогостоящие ошибки:

• «Начали на Firestore, а потом понадобился разрез по 12 измерениям и JOIN по истории событий».
• «Построили мульти‑тенантность в приложении без RLS — в инцидент попали все клиенты».
• «Не учли cold starts Neon и таймауты лямбд — первый запрос к API иногда тормозит».
• «Плодили Edge Functions вместо очередей/воркеров — уперлись в лимиты платформы».

Рекомендации MTBYTE: когда что брать

• 70% B2B SaaS с отчетностью, ролями, аудитом: Supabase или Neon. Нужны быстрый старт и минимум интеграций — Supabase. Нужна гибкость, KMS/секреты, свой observability — Neon + ваш фреймворк.
• Мобильные продукты с упором в live‑синхронизацию, минимальной отчетностью и агрессивным time‑to‑market — Firebase. Но сразу проектируйте экспорт в BigQuery и подумайте, как будете считать «месячный отчет».
• Гибрид: Neon (основной OLTP), Kafka/Redpanda (события), Tiny realtime через Postgres NOTIFY + WebSocket, Auth0/Clerk, S3/R2 для объектов. Это снижает вендор‑лок и хорошо ложится в мультизонную стратегию.

Архитектура потока для гибрида:

• Клиент -> Next.js API Route (edge‑кеш для GET) -> Auth middleware (Clerk) -> Бизнес‑логика в NestJS -> Neon (через Prisma/pg) -> события в Redis Stream/Kafka -> воркеры (Temporal/Cloud Run) -> вебхуки в Stripe/Slack -> обратные записи в БД для аудита.
• Файлы: прямые загрузки в R2 через pre‑signed URL, метаданные — в Postgres.
• Поиск: pg_trgm для простой подстроки, Elastic/Meilisearch при росте требований.

Если остались сомнения, выбирайте Postgres‑ветку. SQL редко становится проблемой через год, в отличие от обратной миграции из документа в нормализованную схему.

FAQ

Q: Можно ли взять Neon как БД, а Auth и Storage — от Supabase?

A: Формально да: Supabase Auth/Storage можно использовать отдельно от их Postgres, но вы потеряете часть удобства tight‑интеграции (RLS‑привязка к JWT, триггеры). Чаще разумнее собрать Auth на Clerk/Auth0 и хранение в R2/S3.

Q: Что лучше для GDPR и региональности?

A: У всех трех есть варианты размещения в ЕС. Важно не только «где сервер», но и потоки данных (вебхуки, логирование, бэкапы). Для строгих требований проще контролировать цепочку на Neon или «самом Postgres», но Supabase тоже поддерживает регионы ЕС.

Q: Как мигрировать с Firebase на Postgres?

A: Экспорт коллекций в JSON/BigQuery, проектирование схемы (нормализация), написание ETL (dbt/Airbyte/кастомные скрипты), параллельный двойной‑запись (dual‑write) на период, затем переключение клиентов. Сложность — соответствие прав доступа и восстановление инвариантов транзакциями.

Q: Реалтайм на Postgres без Supabase — как?

A: NOTIFY/LISTEN, logical decoding, pgoutput + WebSocket‑шлюз. Для масштабирования — Debezium/pgoutput -> брокер событий -> подписчики. Это чуть сложнее в сборке, но гибко и без вендор‑лока.

Q: Нужен ли ORM (Prisma/Drizzle) или чистый SQL?

A: Для CRUD и быстрой разработки ORM ускоряет команду. Для сложных отчетов и тюннинга — чистый SQL неизбежен. Комбинация: ORM + SQL‑вью/материализованные вью — рабочий компромисс.

Q: Что с холодными стартами и коннектами?

A: На Neon учитывайте прогрев compute и пул коннектов (pgBouncer). На Supabase — ограничение коннектов плана. На Firebase — Cloud Functions холодные старты и лимиты времени; критичное — держите в прогретых воркерах/Cloud Run.

Key takeaways

• Для B2B SaaS с отчетами безопаснее SQL‑ветка: Supabase (быстрый старт) или Neon (гибкость и чистый Postgres).
• Firebase хорош для мобильных realtime‑кейсов, но может стать дорогим и неудобным для BI и сложных JOIN.
• Мульти‑тенантность делайте на уровне БД (RLS в Postgres); апп‑фильтры рано или поздно подведут.
• Планируйте очереди/воркеры и идемпотентные вебхуки; тяжелое — вне Edge/Functions.
• Считайте TCO: не только тариф, но и стоимость миграций, ETL и работы команды.

Если вы строите SaaS и выбираете между Supabase, Firebase и Neon, MTBYTE может спроектировать архитектуру, оценить TCO и собрать MVP/прод за недели. Напишите нам: /contact.