Supabase или Firebase (2026): на каком бэкенде строить ИИ-приложение

Выбирайте Supabase, если ваше приложение построено вокруг данных, вам нужен SQL и вы допускаете, что однажды захотите уйти. Выбирайте Firebase, если вы выпускаете мобильное приложение реального времени и не хотите в первый же день возиться с настройкой оплаты. Всё остальное — это математика затрат и две стены, в которые упирается каждый из них.

Оба сервиса — это «backend-as-a-service»: база данных, аутентификация, файловое хранилище и API берутся на себя платформой, так что вам не нужно поднимать сервер. На этом сходство заканчивается. Они хранят данные в принципиально разных формах, тарифицируют по противоположным моделям, и от одного из них можно уйти, а от другого — по сути нет. Для ИИ-приложения в 2026 году эти три отличия решают больше, чем любой список функций.

Сначала короткий вывод, потом расчёты, которые его подтверждают.

Что выбрать в зависимости от того, что вы строите

Если ваше приложение — это в основном таблицы, связанные друг с другом (пользователи, заказы, посты, комментарии), и вы умеете писать или хотя бы читать SQL, стройте на Supabase. Вы получаете настоящую базу PostgreSQL, а значит джойны, транзакции и схему, которая останавливает плохие данные на входе. Она к тому же с открытым кодом: в тот день, когда хостинг-тариф станет вам тесен, вы забираете базу целиком и запускаете её где угодно. Ценность этой запасной двери большинство основателей осознаёт только тогда, когда она действительно понадобится.

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

Всё, что ниже, — о том, как эти два решения держатся перед реальными ценами, реальными ИИ-функциями и теми подводными камнями, которые решают исход, когда вы уже в продакшене.

Единственный критерий, который решает всё

Уберите списки функций — и останется один вопрос: вы владеете базой данных, которую можно забрать, или арендуете сервис, из которого нельзя выйти?

Supabase — это PostgreSQL с панелью управления сверху. PostgreSQL — самая распространённая реляционная СУБД с открытым кодом в мире, и Supabase её не форкает и не прячет. Вы получаете обычную строку подключения. Если однажды захотите переехать на свой сервер, в AWS или к другому хостеру, вы выполняете стандартный pg_dump — и вы свободны. В ваших данных нет ничего проприетарного.

Firebase — это Firestore, документная NoSQL-база, которая существует только внутри Google. NoSQL означает, что фиксированной схемы нет: вы сохраняете документы, похожие на JSON, и база не навязывает связи между ними. Ранняя прототипизация от этого становится быстрой, потому что вы ни разу не останавливаетесь, чтобы спроектировать таблицы. Но это же означает: нет SQL, нет настоящих джойнов и нет чистого способа выгрузить свои данные в другую систему потом. Модель данных и вендор — это одно и то же решение. Firestore забрать с собой нельзя.

Для большинства ИИ-приложений ответ склоняется к Supabase, потому что ИИ-функции опираются на структурированные данные, к которым можно делать запросы: таблица пользователей, таблица документов, колонка эмбеддингов, по которой можно фильтровать и джойнить. NoSQL это тоже умеет, но вы в итоге воссоздаёте в коде приложения то, что SQL даёт бесплатно. Исключение — когда «мгновенная синхронизация между устройствами» и есть сам продукт. Это единственное, что Firestore делает лучше всех.

:::callout{variant="note" title="Что на практике даёт "реляционность""}
Допустим, пользователь удаляет аккаунт, и вместе с ним должны исчезнуть все его комментарии, лайки и файлы. В PostgreSQL это правило описывается один раз (внешний ключ с каскадным удалением), и база соблюдает его всегда. В Firestore вы сами пишете код, который находит и удаляет каждый связанный документ, и если пропустите хотя бы один путь — осиротевшие данные будут копиться. Реляционные базы делают «связанные данные остаются согласованными» задачей базы, а не вашей.
:::

Цены: та часть, где ошибаются почти все

Главное — не месячная сумма. Главное — модель тарификации. Supabase берёт фиксированный тариф плюс предсказуемую переплату за превышение; Firebase считает по операциям, поэтому ваш счёт двигается вместе с трафиком, иногда за одну ночь.

Supabase: фиксированное число, под которое можно планировать

Supabase Free стоит $0 и покрывает настоящее приложение: 50 000 активных пользователей в месяц, база на 500 MB, 5 GB исходящего трафика и 1 GB файлового хранилища. Подвох, на который натыкаются все: бесплатные проекты засыпают после недели простоя, и активных проектов может быть не больше 2. Уснувший проект означает, что ваше демо лежит, пока вы не нажмёте кнопку восстановления. Для пет-проекта это нормально, для чего угодно, что клиент может открыть без предупреждения, — проблема.

Supabase Pro стоит $25 в месяц, первый проект включён, дополнительные — от $10 в месяц. За эти $25 вы получаете 100 000 MAU (дальше $0.00325 за каждого сверх), 8 GB диска на проект (дальше $0.125/GB), 250 GB исходящего трафика (дальше $0.09/GB) и 100 GB файлового хранилища (дальше $0.0213/GB). Сюда же входят $10 в месяц вычислительных кредитов — этого хватает на один небольшой инстанс, работающий постоянно. Тариф Team прыгает до $599 в месяц и добавляет в основном соответствие стандартам (SOC2, ISO, SSO); ниже этого уровня он вам не нужен.

Почему разработчикам нравится такая модель: вы смотрите на число пользователей и знаете свой счёт. Pro за $25 покрывает настоящее продакшен-приложение, а ставки за превышение достаточно низкие, чтобы 10 000 активных пользователей с несколькими гигабайтами данных по-прежнему укладывались в диапазон от $25 до $50.

Firebase: бесплатно, пока не перестанет, а дальше по счётчику

Firebase Spark — по-настоящему бесплатный тариф, и его главное достоинство в том, что платёжный метод не нужен вообще. Вы получаете Firestore с 1 GiB хранения, 50K чтений в день, 20K записей в день, 20K удалений в день и 10 GiB исходящего трафика в месяц; Authentication на 50K активных пользователей в месяц; и Realtime Database с 1 GB хранения и 10 GB загрузок в месяц. Для прототипа или приложения с небольшим трафиком можно сидеть на Spark бесконечно и не платить ничего, без карты в системе.

Как только вам понадобится больше, вы переходите на Blaze — тариф pay-as-you-go (Google даёт $300 бесплатных кредитов, если вы подходите под условия). Blaze сохраняет бесплатные лимиты Spark, а всё сверх них считает по счётчику: Cloud Functions — 2M вызовов в месяц бесплатно, дальше $0.40 за миллион; Cloud Storage — $0.026/GB хранения после 5 GB и $0.12/GB на скачивание после 1 GB в день; чтения, записи и удаления в Firestore сверх дневного бесплатного лимита тарифицируются за операцию по прайсу Google Cloud. Firebase теперь предлагает и управляемый PostgreSQL через SQL Connect: 3 месяца бесплатного пробного периода, дальше примерно от $9.37 в месяц. Тихое признание того, что SQL в итоге нужен многим.

Бесплатные тарифы лицом к лицу

Оба дают 50 000 активных пользователей в месяц бесплатно, и этого более чем достаточно, чтобы проверить почти любую гипотезу. Разница — в двух подвохах.

Подвох Supabase — засыпание: оставьте бесплатный проект без дела на неделю, и он уснёт, пока вы его не разбудите. Раздражает на демо и становится неважным, как только появляется реальный трафик или вы переходите на Pro.

Подвох Firebase — обрыв при апгрейде: Spark действительно бесплатен и без карты, но в момент, когда вы его перерастаете, вы оказываетесь на тарификации по счётчику, а она непредсказуема по своей конструкции. Здесь нет тарифа за $25 в духе «дайте просто немного больше за фиксированную цену». Вы переходите от бесплатного к оплате за использование одним шагом.

Отсюда честный вывод по бесплатным тарифам: Firebase выигрывает для прототипа без обязательств, который вы, возможно, никогда не будете монетизировать, — ни карты, ни засыпания. Supabase выигрывает в тот момент, когда проект становится настоящим, потому что фиксированные $25 лучше, чем «мы посчитаем ваше потребление, а там посмотрим».

Supabase или Firebase: на чём строить ИИ-приложение

Именно здесь 2026 год реально отличается от 2022-го, и именно здесь Supabase вырывается вперёд для большинства разработчиков. ИИ-приложению обычно нужно хранить эмбеддинги (числовые отпечатки вашего текста) и находить ближайшие совпадения к запросу. Это и есть векторный поиск — движок, стоящий за retrieval, семантическим поиском и RAG (retrieval-augmented generation, когда вы скармливаете LLM собственные документы).

Supabase даёт это нативно через pgvector — расширение PostgreSQL, которое хранит и индексирует векторы прямо рядом с обычными данными. Поскольку база одна, вы можете выполнить один запрос, который одновременно фильтрует по ID пользователя и ранжирует по векторной близости. Никакой второй системы, никакой синхронизации. ИИ-тулкит Supabase также подключается напрямую к эмбеддингам OpenAI и Hugging Face.

Firebase отвечает векторным поиском в Firestore через запрос findNearest: эмбеддинги можно хранить в документе и получать ближайших соседей, не выходя из Firestore. Это работает, и если вы уже глубоко внутри Firestore, вы экономите себе вторую базу. Но вы выполняете векторную математику в документном хранилище, которое вокруг неё не проектировалось, и теряете SQL-фильтрацию, благодаря которой запросы к pgvector выглядят так чисто. Для приложения, где ИИ на первом месте, pgvector — более естественный дом.

1. 1

   Как сохранить эмбеддинг в Supabase

   Включите расширение командой create extension vector;, добавьте в таблицу колонку вида embedding vector(1536), затем вставьте массив эмбеддинга рядом с обычными данными строки. Одна таблица хранит и ваш контент, и его вектор.

2. 2

   Как найти ближайшие совпадения

   Выполните обычный select, отсортированный по оператору векторного расстояния (embedding <=> query_embedding), с limit. В тот же запрос можно добавить привычное where user_id = ..., так что поиск по близости и контроль доступа происходят за один заход.

3. 3

   Как проиндексировать, чтобы оставалось быстро

   Добавьте индекс HNSW на векторную колонку. Он сохраняет скорость поиска ближайших соседей по мере роста таблицы — ровно так же, как обычный индекс ускоряет обычную колонку.

Аутентификация, real-time и всё остальное

Оба сервиса хорошо закрывают аутентификацию. Firebase Auth зрелее: длинный список провайдеров и самые гладкие мобильные SDK. Если «пусть пользователи просто входят» должно работать на iOS и Android без сюрпризов — это отличный выбор. Supabase Auth построена на вашей базе Postgres и работает в паре с RLS (row-level security: каждый пользователь может читать и писать только свои строки, и это обеспечивает сама база). RLS — самая важная концепция Supabase, которую нужно освоить, потому что именно она делает многопользовательское приложение безопасным без проверок прав в каждом вызове API.

Real-time — родная территория Firebase. Firestore и Realtime Database синхронизируют состояние между устройствами и аккуратно обрабатывают офлайн, ставя записи в очередь и проигрывая их заново, когда связь возвращается. У Supabase тоже есть Realtime, построенный на потоке изменений Postgres, и он хорош для живых дашбордов и индикации присутствия, но это не тот офлайн-first опыт, на который опираются мобильные приложения на Firebase. Если ваш продукт — совместное или сильно офлайновое мобильное приложение, дайте этому пункту большой вес в пользу Firebase.

Правило выбора в зависимости от того, кто вы

Что лучше — Supabase или Firebase?

Ни то ни другое не лучше всегда. Supabase лучше для приложений с большим объёмом данных, которым нужен SQL, ИИ-функции и свобода мигрировать позже. Firebase лучше для мобильных приложений реального времени с офлайн-first подходом и для прототипов без обязательств, где не нужна банковская карта. Подбирайте инструмент под то, что является вашей ключевой функцией: структурированные данные или живая синхронизация.

Правда ли, что Google закрывает Firebase?

Нет, Google не закрывает Firebase. Путаница возникает из-за того, что отдельные устаревшие продукты выводятся из эксплуатации (например, Firebase Dynamic Links закрылся в августе 2025 года) и из-за того, что часть возможностей Google перенёс в Google Cloud. Основная платформа активно развивается, а среди недавних добавлений — Firebase Studio, AI Logic и управляемый PostgreSQL через SQL Connect.

Supabase — это часть Firebase?

Нет. Supabase — отдельная независимая компания, которую часто описывают как альтернативу Firebase с открытым кодом. Она даёт такой же универсальный бэкенд (база данных, аутентификация, хранилище, API), но построенный на PostgreSQL, а не на проприетарном Firestore от Google.

Какие у Supabase недостатки?

Их два главных. Бесплатные проекты засыпают после недели простоя, что мешает демонстрациям. И его real-time с офлайн-синхронизацией, при всей своей надёжности, менее зрелый, чем у Firebase: для сильно офлайновых мобильных приложений Firebase всё ещё впереди. Кроме того, вам придётся освоить RLS, чтобы многопользовательские приложения оставались безопасными.

Что дешевле — Supabase или Firebase?

Для прототипа вообще без трафика дешевле Firebase Spark, потому что он бесплатен и не требует карты. Как только появляется реальное потребление, Supabase обычно дешевле и куда предсказуемее: фиксированные $25 в месяц на тарифе Pro против оплаты за операцию у Firebase, которая растёт вместе с трафиком. Чем больше ваше приложение читает и пишет, тем чаще выигрывает фиксированная модель Supabase.

Выберите бэкенд, а потом подгоните под него остальной стек. Раз в неделю я присылаю один такой разбор инструмента — с реальными затратами и стенами включительно. Получать на почту.