Supabase vs Firebase 2026: честное техническое сравнение
Каждый новый проект ставит один и тот же вопрос: поднимать Postgres + auth + storage самому или взять готовую платформу? В 2026 году три варианта заслуживают серьёзного рассмотрения. Это технический разбор без маркетинга.
Коротко о каждом
- Firebase — зрелый, Google-backed, проприетарный, дорог при масштабировании
- Supabase — open-source, PostgreSQL внутри, можно самохостить, активно развивается
- PocketBase — один Go-бинарник, SQLite, непобедим для MVP и небольших проектов
Модель данных: ключевое отличие
Firebase (Firestore)
NoSQL документная база. Хорошо для иерархических данных с realtime-подписками:
// Вложенные коллекции
const orderRef = db.collection('users').doc(userId)
.collection('orders').doc(orderId);
await orderRef.set({
items: [{ productId: 'abc', qty: 2 }],
total: 4500,
createdAt: serverTimestamp(),
});
// Realtime-подписка
onSnapshot(orderRef, (doc) => console.log(doc.data()));
Проблема: нет JOIN. Нужны «все заказы с деталями продуктов» → запрашиваете заказы, потом N запросов на каждый продукт. При 1000 заказах = 1001 чтение. Деньги + latency.
Supabase (PostgreSQL)
Полноценный реляционный SQL. JOIN, CTE, представления, хранимые функции, полнотекстовый поиск, PostGIS:
// Один запрос вместо тысячи
const { data } = await supabase
.from('orders')
.select(`
id, total, created_at,
order_items (
quantity,
products ( name, price, sku )
)
`)
.eq('user_id', userId)
.order('created_at', { ascending: false })
.limit(20);
Один запрос. JOIN на стороне сервера. Для большинства бизнес-приложений это и решает выбор.
PocketBase
SQLite с REST/realtime API. Вся схема + авторизация + файлы в одном файле:
const records = await pb.collection('orders').getList(1, 20, {
filter: `user = "${userId}"`,
expand: 'items,items.product',
sort: '-created',
});
SQLite → единственный writer. Нормально для небольших нагрузок, не подходит для высокочастотной записи.
Аутентификация
Все три поддерживают email/password, OAuth (Google, GitHub, Apple), magic links.
Firebase Auth
import { signInWithPopup, GoogleAuthProvider } from 'firebase/auth';
const result = await signInWithPopup(auth, new GoogleAuthProvider());
const idToken = await result.user.getIdToken();
Кастомные claims для RBAC:
// Cloud Function
await admin.auth().setCustomUserClaims(uid, { role: 'admin' });
Зрелый, хорошо документирован. Но верификация JWT требует Firebase Admin SDK.
Supabase Auth + Row Level Security
Убийственная фича: безопасность прямо на уровне базы данных:
-- Политика: пользователи видят только свои заказы
CREATE POLICY "Users see own orders"
ON orders FOR SELECT
USING (auth.uid() = user_id);
// RLS применяется автоматически
const { data: { user } } = await supabase.auth.getUser();
const { data: orders } = await supabase.from('orders').select('*');
// Вернёт ТОЛЬКО заказы текущего пользователя
Забыть про проверку прав в API-коде невозможно — она в базе.
Realtime
Firebase
Realtime как первый класс — именно для этого создавался:
const unsubscribe = onSnapshot(
query(collection(db, 'messages'), where('chatId', '==', chatId)),
(snapshot) => {
snapshot.docChanges().forEach(change => {
if (change.type === 'added') addMessage(change.doc.data());
});
}
);
Supabase Realtime
Postgres changes через logical replication → WebSocket:
const channel = supabase
.channel('orders-changes')
.on(
'postgres_changes',
{ event: 'INSERT', schema: 'public', table: 'orders', filter: `user_id=eq.${userId}` },
(payload) => console.log('Новый заказ:', payload.new)
)
.subscribe();
Плюс Broadcast (произвольные сообщения между клиентами) и Presence (кто онлайн) — у Firebase этого нет из коробки.
Цены при масштабировании
| MAU | Firebase | Supabase | PocketBase |
|---|---|---|---|
| 10k | Бесплатно | Бесплатно | ~500₽/мес (VPS) |
| 100k | ~4 000-16 000₽ | 2 000₽/мес (Pro) | ~1 500₽/мес |
| 1M | ~160 000-640 000₽ | ~48 000₽+ | ~8 000₽/мес |
| 10M | ~1.6M-6.4M₽ | Enterprise | ~60 000₽/мес |
Firebase платит за чтения/записи/хранение. 10M прочтений документов = $3. Одна неоптимальная выборка умножает расходы в 100 раз.
Supabase: плата за compute/bandwidth — предсказуемо, как managed Postgres.
PocketBase: платите только за VPS.
Самохостинг
| Возможность | Firebase | Supabase | PocketBase |
|---|---|---|---|
| Самохостинг | Нет | Да (сложно) | Да (тривиально) |
| Vendor lock-in | Высокий | Низкий | Нулевой |
| Экспорт данных | JSON | Полный Postgres dump | SQLite файл |
Supabase self-hosting — Docker Compose с ~6 контейнерами:
services:
db:
image: supabase/postgres:15.1.0.54
auth:
image: supabase/gotrue:v2.132.3
rest:
image: postgrest/postgrest:v12.0.2
realtime:
image: supabase/realtime:latest
storage:
image: supabase/storage-api:latest
Работает, но не «тривиально». Нужно понимать как это всё обслуживать.
PocketBase: скачать бинарник → запустить → всё:
./pocketbase serve --http="0.0.0.0:8090"
Когда что выбирать
Firebase:
- Команда уже знакома с Google Cloud
- Данные действительно документоориентированные
- Нужен проверенный realtime при нагрузке в миллионы пользователей
- Есть бюджет на масштабирование
Supabase:
- Реляционные данные (пользователи, заказы, продукты — подавляющее большинство проектов)
- Важна открытость и возможность перейти на собственный хостинг
- Row Level Security — нужна безопасность на уровне БД
- Команда знает SQL
PocketBase:
- MVP, прототип, внутренний инструмент
- Соло-разработчик или небольшая команда
- Умеренный трафик (до ~10k одновременных пользователей)
- Нулевая сложность инфраструктуры
- Бюджет — главный приоритет
Итог 2026
Для большинства веб и мобильных приложений с реляционными данными: Supabase. PostgreSQL + RLS + realtime — сильная комбинация, которую трудно превзойти.
Для крупных команд с Google Cloud и гарантированными миллионами пользователей: Firebase по-прежнему самое зрелое решение.
Для хакатонов, MVP и небольших production-приложений: PocketBase — один бинарник, полный стек.
Aunimeda строит production-приложения на современной BaaS-инфраструктуре. Обсудим архитектуру.
Смотрите также: tRPC + Zod типобезопасность, Next.js 15 App Router