Supabase или Firebase для MVP: счёт за чтения меняет выбор базы

Для первого продукта со связанными данными и частыми выборками разумно начать сравнение с Supabase и его базой PostgreSQL. Если главное требование — работа мобильного приложения без сети с последующей синхронизацией, преимущество у Firebase с Cloud Firestore. Выбор меняется вместе с нагрузкой: Firestore считает прочитанные документы, а расходы Supabase зависят прежде всего от плана, выделенных вычислительных ресурсов и использования включённых квот.

Речь идёт именно о сравнении PostgreSQL в Supabase с Cloud Firestore в Firebase, а не всех продуктов двух платформ. Согласно документации Firestore об автономной работе, мобильный клиент хранит используемые данные локально и синхронизирует изменения после восстановления связи; на Android и устройствах Apple постоянное локальное хранение включено по умолчанию. Для приложения, которым пользуются в дороге или при нестабильном соединении, это сокращает объём работы над первым выпуском.

За что выставляют счёт

В Cloud Firestore запрос, вернувший много документов, может создать много оплачиваемых чтений. Тариф Google Cloud для Firestore Standard учитывает чтения документов и, в некоторых запросах, записей индекса, а также записи, удаления, хранение и исходящий трафик. Для выбранного в тарифной таблице региона Айова после бесплатной квоты чтения стоят $0,03 за 100 тысяч документов, записи — $0,09 за 100 тысяч; бесплатно предоставляются 50 тысяч чтений и 20 тысяч записей в день.

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

У Supabase другая единица расчёта. Правила выставления счетов Supabase закрепляют вычислительные расходы за отдельным экземпляром PostgreSQL каждого проекта, а переменные квоты, включая исходящий трафик, считают на уровне организации. Отдельной платы за каждую прочитанную строку SQL в этой модели нет. Частые или тяжёлые запросы всё равно нагружают экземпляр, и при переходе на более мощный размер вычислительная часть счёта вырастет.

Тариф Supabase Pro начинается с $25 в месяц: платный план включает вычислительный кредит на один экземпляр Micro, 8 ГБ диска на проект и 250 ГБ исходящего трафика. Это нижний ориентир для проекта, который укладывается в квоты и работает на Micro, а не фиксированная цена при любой нагрузке. Изменение размера экземпляра, дополнительные проекты и превышение квот меняют итоговую сумму.

Связанные данные и частые запросы

Возьмём условный сервис заказов, в котором связаны пользователи, заказы и позиции заказа. Предположим, ежедневно им пользуются 20 тысяч человек, каждый получает 200 документов Firestore и создаёт пять записей. За условные 30 дней это 120 миллионов чтений и три миллиона записей. Речь именно о документах, полученных клиентами, а не о количестве запусков приложения или сетевых запросов.

При равномерной нагрузке ежедневная бесплатная квота за этот период покроет 1,5 миллиона чтений и 600 тысяч записей. Останутся 118,5 миллиона оплачиваемых чтений на $35,55 и 2,4 миллиона записей на $2,16. Итого получится $37,71 за эти операции. В условном расчёте нет платных чтений индекса и правил доступа, хранения, трафика и других услуг; неиспользованная дневная квота на следующий день не переносится.

В реляционной базе связанные сущности можно получать запросами с соединением таблиц. Это не делает каждый запрос бесплатным с точки зрения ресурсов: сложная выборка потребляет память и время процессора, а плохо подобранные индексы усиливают нагрузку. Зато стоимость не растёт автоматически на определённую сумму за каждый документ, который увидел клиент. Поэтому количество чтений Firestore нельзя механически превратить в число запросов или стоимость PostgreSQL.

В этом сценарии рассчитанная плата Firestore только за чтения и записи уже выше начальной цены Pro. Такой результат сам по себе не доказывает, что Supabase обойдётся дешевле: неизвестно, выдержит ли экземпляр Micro пиковые запросы и сколько трафика создаст сервис. Он показывает более узкое, но важное последствие выбора модели оплаты: при частой доставке документов операционная часть счёта Firestore может стать заметной ещё до расходов на хранение и передачу данных.

Мобильное приложение с автономной синхронизацией

Теперь рассмотрим другое условное приложение — личные заметки с двумя тысячами ежедневных пользователей. Пусть каждый за день получает 30 документов и делает две записи. За те же 30 дней приложение выполнит 1,8 миллиона чтений и 120 тысяч записей. При равномерной активности бесплатная дневная квота покрывает все записи и 1,5 миллиона чтений; оставшиеся 300 тысяч чтений стоят $0,09 по выбранной ставке.

Это расчёт операций базы, а не полного счёта за приложение. Он предполагает, что клиент не перечитывает большие подборки при каждом открытии и не доставляет каждое изменение множеству подписчиков. Если заметки содержат вложения или активно передаются между устройствами, расходы на хранение и трафик нужно считать отдельно. При небольшом числе документов плата за чтения остаётся скромной, а готовое автономное поведение Firestore может оказаться важнее разницы в стартовых ценах планов.

Автономность при этом имеет конкретные границы. Клиент показывает локально сохранённые данные, которые до синхронизации могут отличаться от состояния на сервере; для нескольких изменений одного документа Firestore применяет правило последней записи. В приложении с заметками это может быть приемлемо, а для совместного редактирования потребуется продумать конфликты. При выборе Supabase локальную базу, очередь изменений и разрешение конфликтов придётся предусмотреть в устройстве клиента либо подключить отдельное решение.

Что означают опубликованные задержки

В замерах CBStack для 10 тысяч активных подписок указаны медианная задержка доставки обновления 38 мс и 95 мс на 99-м процентиле для связки Supabase Realtime, против 45 и 120 мс для Cloud Firestore. Авторы описывают конфигурацию Supabase с 2 виртуальными процессорами и 8 ГБ памяти. Это измерение доставки обновлений подписчикам, а не времени выполнения произвольного SQL-запроса.

На той же странице приведён ещё один набор результатов для иной конфигурации. Описанный в первом замере экземпляр крупнее базового Micro, поэтому цифры нельзя переносить на стартовую цену Supabase. Задержка собственного приложения будет зависеть от региона клиентов, размера изменений, настроек подписок и нагрузки. Для выбора базы эти измерения дают ориентир о конкретной схеме доставки обновлений, но не заменяют расчёт расходов и требований к автономной работе.

Какой выбор следует из двух сценариев

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

Если центральная функция — работа мобильного клиента без сети, Cloud Firestore предлагает встроенное локальное хранение и синхронизацию. При умеренном числе документов условный расчёт даёт небольшую плату за операции; при частых обновлениях и множестве подписчиков оплачиваемые чтения быстро накапливаются. Поэтому для такого приложения решающим становится не само наличие подписок, а число документов, которые каждая из них доставляет пользователям.

Читайте также:

• 25 приложений для чтения: где бесплатная читалка выгоднее подписки
• Удобное приложение не защищает счёт: как выбрать брокера со смартфона
• Midjourney или Ideogram: читаемый текст меняет выбор генератора