Supabase против Firebase: что выбрать под MVP

Оба закрывают одну задачу: бэкенд для MVP без написания бэкенда. Различаются они в основании, и это различие определяет всё остальное.

Модель данных

Supabase - реляционная база. Таблицы, связи, внешние ключи, SQL. Запрос со связями пишется один раз и выполняется одним обращением.

Firebase - документное хранилище. Данные лежат документами, связей в привычном смысле нет. Запросы проще, но связывание данных ложится на приложение: то, что в SQL является одним запросом, здесь превращается в несколько обращений и сборку на клиенте.

Практическое следствие: выбор определяется тем, насколько связаны ваши данные.

• Связаны сильно (заказы, позиции, клиенты, статусы) - реляционная модель проще и предсказуемее.
• Связаны слабо (независимые записи, ленты, документы) - документная модель удобнее.

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

Цена на росте

Считать надо по своему профилю нагрузки, а не по сравнению тарифных страниц: тарифицируются разные вещи.

Документное хранилище обычно берёт деньги за операции чтения и записи. Приложение, которое часто читает мелкие документы, набирает их быстро. Классический сюрприз - лента, обновляющаяся у всех пользователей.

Реляционная база обычно берёт за ресурсы, хранилище и трафик. Много мелких запросов дешевле, но неоптимальный тяжёлый запрос ощутим.

Оценивать стоит по вопросу: что у вас будет расти быстрее - число операций или объём данных? Ответ обычно и определяет, что окажется дороже.

Привязка к поставщику

Здесь различие существенное.

Supabase. Под ним обычный PostgreSQL. База переносится вместе со схемой на любой хостинг или на свой сервер. Переписать придётся обвязку: авторизацию, доступ к данным, функции. Данные при этом ваши и в стандартном формате.

Firebase. Данные выгрузить можно, но модель, запросы и правила доступа привязаны к сервису. Перенос означает не только смену хранилища, но и пересборку модели данных.

Практическое правило: чем менее уникален ваш бэкенд, тем меньше значит вендор-лок. Для прототипа это не аргумент вовсе; для продукта, который планируется на годы, - существенный.

Как выбрать

Пять вопросов, закрывающих решение:

1. Данные связаны между собой? Да - реляционная модель.
2. Умеете в SQL? Да - реляционная. Нет - документная проще на старте.
3. Мобильное приложение с офлайн-режимом в приоритете? Синхронизация офлайна проработана лучше у документного варианта.
4. Есть требования к размещению данных? Тогда нужен self-hosted, и это решает вопрос.
5. Что будет расти быстрее - операции или объём? Это определит счёт.

И общее замечание: на масштабе прототипа разница невелика. Оба варианта дадут работающий бэкенд за дни. Различия проявляются на росте, поэтому выбирать стоит по тому, куда вы планируете расти, а не по удобству первой недели.

Что именно даёт Supabase - гид. Где ломаются проекты на нём - авторизация и RLS.