Firebase от Google: что это и когда он лучше Supabase

Ты дошёл до момента, когда приложению нужен настоящий бэкенд: где-то хранить пользователей, их данные и файлы, а не только рекорд в localStorage на одном компьютере. На курсе мы уже подробно разобрали Supabase — и тут почти каждый спрашивает: «А что насчёт Firebase? Все же про него говорят». Говорят не зря: поисковый запрос «firebase» набирает тысячи показов в месяц, а «firebase console» и «google firebase» — ещё сотни сверху. Это один из самых популярных способов вообще собрать бэкенд для приложения. В этой статье честно разберём, что такое Firebase простыми словами, чем он принципиально отличается от Supabase, в каких проектах он удобнее, а в каких — наоборот, есть ли бесплатный тариф и какие подводные камни стоит знать до того, как ты напишешь первую строчку кода.

Что такое Firebase простыми словами

Firebase — это платформа от Google для быстрого создания бэкенда приложения без своего сервера. Бэкенд — это «невидимая» часть приложения: та, что хранит данные, проверяет логины и пароли, раздаёт файлы и рассылает уведомления. Обычно для бэкенда нужно арендовать сервер, поставить на него базу данных, написать серверный код, настроить резервное копирование и следить, чтобы всё это не упало посреди ночи. Firebase берёт эту работу на себя: ты получаешь готовые сервисы в облаке Google и подключаешь их к своему приложению через SDK — готовую библиотеку, которая добавляется в проект несколькими строками кода. Такой подход называют «бэкенд как сервис»: вместо того чтобы строить и обслуживать инфраструктуру, ты арендуешь её в готовом виде и платишь вниманием только за настройку.

Аналогия из жизни: Firebase и Supabase — это как аренда квартиры со всей мебелью и техникой. Ты не строишь дом (свой сервер), не покупаешь диван (не настраиваешь базу с нуля) — просто въезжаешь и живёшь, а поломку крана чинит хозяин. Разница между сервисами в том, кто хозяин квартиры, как расставлена мебель и можно ли эту мебель когда-нибудь забрать с собой при переезде.

Что входит в набор Firebase:

• Firestore — база данных, которая обновляется в реальном времени: изменил запись на одном устройстве — она тут же поменялась на всех остальных, без обновления страницы.
• Authentication — готовая авторизация пользователей: вход по email и паролю, через Google-аккаунт, по номеру телефона и другими способами.
• Cloud Storage — хранилище файлов: аватарки, картинки, документы и любые другие файлы пользователей.
• Hosting — место, где живёт само приложение, чтобы его можно было открыть по публичной ссылке.
• Cloud Messaging — push-уведомления на телефоны: те самые всплывающие сообщения, которые приходят от приложений, даже когда они закрыты.
• Analytics — встроенная аналитика Google Analytics: кто заходит, откуда, что нажимает.

По сути, это «бэкенд в коробке»: база плюс авторизация плюс хранилище файлов плюс хостинг плюс уведомления — всё в одной консоли и с одним аккаунтом Google. Работаешь с платформой через Firebase console — веб-интерфейс, в котором создаётся проект, включаются нужные сервисы и просматриваются данные. Именно эту консоль и имеют в виду сотни людей в месяц, вбивая в поиск «firebase console».

Для вайбкодера важно другое: всё это подключается промптом. Ты говоришь ИИ-ассистенту «подключи к проекту Firebase: вход через Google и сохранение результатов в Firestore» — и получаешь готовый код подключения, который остаётся только проверить. Понимать, что происходит под капотом, всё равно нужно — и сейчас разберёмся почему.

Чтобы термины не пугали, закрепим на примере. Допустим, ты делаешь мобильную игру. Игрок открывает приложение — срабатывает Authentication, и игрок входит через Google-аккаунт, без придумывания пароля. Игрок набирает очки — результат улетает документом в Firestore, и все его устройства видят одинаковое состояние. Игрок загружает аватарку — файл ложится в Cloud Storage, а в базе остаётся только ссылка на него. Прошла неделя, игрок забыл про игру — Cloud Messaging присылает ему push «Твой рекорд побили». Само приложение при этом лежит на Firebase Hosting и открывается по ссылке. Вся эта цепочка собирается внутри одной консоли, и ни разу в ней не появляется твой собственный сервер.

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

Чем Firebase отличается от Supabase

Supabase мы уже подробно разобрали на курсе в нескольких статьях: как устроен мультиплеер на Supabase Realtime, как работают RLS-политики безопасности и как сделать общую таблицу рекордов. Поэтому здесь — только суть различий, без повторения уже пройденного.

Главное различие — в фундаменте, то есть в самой базе данных:

• Supabase построен на классической реляционной базе Postgres. Данные живут в строгих таблицах: у таблицы «игроки» есть колонки «имя», «очки», «дата», и между таблицами можно строить связи — например, каждый рекорд ссылается на конкретного игрока. Запросы пишутся на SQL — языке, который уже полвека используют базы данных по всему миру. Безопасность настраивается через RLS-политики — правила на уровне отдельных строк таблицы: «пользователь видит и меняет только свои строки».
• Firebase использует NoSQL-базу Firestore. Там нет таблиц и нет SQL. Вместо этого — документы: гибкие записи, похожие на JSON-объекты, без жёсткой схемы. Документы объединяются в коллекции, у одного документа могут быть одни поля, у другого — другие. Это другой подход к хранению данных: гибче на старте, потому что не нужно заранее проектировать структуру, но слабее, когда данные сильно связаны между собой.

Простая аналогия: Postgres — это библиотека с картотекой, где у каждой книги карточка строгого формата и есть ссылки на другие карточки: «автор — см. карточку такую-то». Firestore — это папка с листами, куда ты кладёшь записи в свободной форме: удобно, пока листов немного и они не обязаны ссылаться друг на друга. Как только листы начинают перекрёстно ссылаться, свободная форма превращается в проблему — никто не проверяет, что ссылка ведёт на существующий лист.

Чтобы разница стала осязаемой, вот как выглядит один и тот же игрок в двух моделях. В Postgres это строка строгой таблицы: имя — текст, очки — число, дата регистрации — дата, и никак иначе. В Firestore это документ — вольная запись: у одного игрока есть поле «любимый скин», у другого его нет, и база не возражает. Свобода приятна, пока однажды код не спрашивает «любимый скин» у игрока, у которого этого поля никогда не было, — и приложение падает там, где строгая таблица просто не дала бы сохранить неполные данные.

Второе различие — открытость. Supabase — проект с открытым кодом: его можно развернуть на своём собственном сервере и ни от кого не зависеть. Firebase — закрытое облако Google: данные живут только у него, и перенести проект куда-то ещё «как есть» нельзя, потому что аналогов Firestore вне Google просто не существует.

Третье различие — специализация. Firebase исторически вырос из мобильной разработки: у него очень глубокая интеграция с Android и iOS, самый зрелый на рынке механизм push-уведомлений и встроенная аналитика. Supabase ближе к веб-разработке и к миру SQL и Postgres.

Сводная таблица для быстрой сверки:

Оба подхода удобны — но для разных задач. Именно поэтому следующие два раздела в этой статье важнее всего.

Когда Firebase удобнее Supabase

Firebase стоит рассмотреть в первую очередь, если у тебя совпадает хотя бы одно из этих условий:

Главный приоритет — мобильное приложение. Если ты собираешься публиковаться в App Store и Google Play, Firebase даёт заметную фору: глубокая интеграция с Android и iOS, готовые push-уведомления через Firebase Cloud Messaging, аналитика Google Analytics встроена сразу, без отдельной настройки и сторонних сервисов. Для мобильной игры или приложения это экономит недели работы — всё «мобильное» уже лежит в одной коробке и одинаково хорошо документировано.

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

Нужна работа в реальном времени «из коробки». Firestore умеет присылать обновления на устройство в момент изменения данных — чат, онлайн-табло, индикатор «кто сейчас в игре» получаются почти без серверного кода: подписался на коллекцию, и изменения прилетают сами. (У Supabase тоже есть режим реального времени — мы собирали на нём мультиплеер, — но у Firebase это исторически главная, самая отполированная функция.)

Хочется минимум настройки на старте. Проект в Firebase создаётся за несколько минут, и первый прототип с регистрацией и сохранением данных реально собрать за вечер — особенно с ИИ-ассистентом, который знает Firebase очень хорошо, потому что платформе много лет и про неё написаны горы примеров.

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

Когда Supabase удобнее Firebase

Обратная ситуация — и для проектов нашего курса она встречается чаще:

Нужны сложные SQL-запросы со связями между таблицами. «Покажи топ-10 игроков недели, у которых есть платная подписка и которые играли в последние три дня» — на SQL это один понятный запрос. В Firestore такое приходится готовить заранее, дублируя данные в специальные документы и обновляя их при каждом изменении. Каждая новая выборка превращается в отдельную инженерную задачу, и чем больше вопросов ты задаёшь своим данным, тем тяжелее.

Важна открытость и независимость. Supabase можно развернуть на своём сервере — и твои данные полностью твои, вместе со всей платформой. Firebase — только облако Google: если однажды сервис изменит условия, тарифы или политику в отношении твоей страны, уйти будет очень сложно. Это называется «привязка к вендору», и у неё есть цена, даже если на старте её не видно.

Ты уже работаешь в экосистеме Postgres. Если в проекте уже есть SQL-база, если ты (или твой ИИ-ассистент) привык писать SQL-запросы — Supabase ляжет естественно, а Firebase добавит второй, несовместимый с первым способ думать о данных. Два разных подхода в одном проекте — это двойная сложность без двойной выгоды.

Безопасность на уровне строк. RLS-политики Supabase — мощный и понятный механизм: «пользователь видит только свои строки» описывается одним правилом прямо в базе, и его мы уже разбирали на практике. У Firestore есть свои правила безопасности, но они пишутся на отдельном языке правил, живут отдельно от данных и проверяются иначе — это ещё одна вещь, которую нужно учить и в которой нужно не ошибиться.

Зачем это знать вайбкодеру на курсе

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

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

Практическое правило для курса простое: учебные проекты и всё, где важны связи между данными (игроки, рекорды, достижения, покупки, подписки), мы делаем на Supabase — он уже разобран, у тебя есть рабочие примеры кода и готовые политики безопасности. Firebase держи в голове как вариант на будущее — если пойдёшь в мобильную разработку с пушами, аналитикой и публикацией в сторах. Знать про оба инструмента нужно не для того, чтобы пользоваться обоими, а для того, чтобы выбор был осознанным.

Как это работает на практике: коротко

Путь пользователя Firebase выглядит так. Создаёшь проект в Firebase console — это бесплатно и занимает пару минут. Затем подключаешь нужные сервисы: включаешь Firestore как базу данных, Authentication как вход для пользователей. В своё приложение добавляешь готовый SDK — библиотеку, которую ИИ-ассистент установит и настроит по твоей просьбе. Дальше в коде появляются вызовы вида «сохрани документ», «дай мне все записи этого пользователя», «подпишись на изменения» — и данные сохраняются и обновляются в реальном времени, без написания и поддержки собственного бэкенд-сервера. Подробные пошаговые инструкции всегда есть в официальной документации: firebase.google.com/docs — интерфейс консоли время от времени меняется, поэтому сверяться лучше с ней, а не со скриншотами в старых статьях.

Если разложить первый вечер работы по шагам, получится примерно такой список:

1. Зайти в Firebase console под своим Google-аккаунтом и нажать «Создать проект».
2. Включить Firestore в тестовом режиме — для разработки этого хватит, боевые правила безопасности настроишь позже.
3. Включить Authentication и отметить нужные способы входа — например, email и Google.
4. Зарегистрировать своё приложение в проекте и получить конфигурацию — набор ключей, который вставляется в код.
5. Попросить ИИ-ассистента подключить SDK и написать первый вызов: сохранить документ и прочитать его обратно.
6. Открыть вкладку с базой в консоли и увидеть свои данные глазами — момент, когда «магия» становится понятной.

Обрати внимание на шаг 6: смотреть на данные в консоли — лучшая привычка новичка. Когда что-то не работает в приложении, первым делом проверь, появилась ли запись в базе. Это сразу делит проблему пополам: либо данные не сохранились, либо не отобразились.

Архитектура типичного приложения на Firebase выглядит так:

flowchart TB
    A["Твоё приложение"] --> B["Firebase Auth — вход пользователей"]
    A --> C["Firestore — база данных"]
    A --> D["Storage — хранилище файлов"]
    A --> E["Cloud Messaging — push-уведомления"]

Обрати внимание: на схеме нет твоего сервера вообще. Приложение напрямую разговаривает с сервисами Google. Это одновременно главная прелесть и главный риск такого подхода. Прелесть — нечему падать, нечего обслуживать и не за что платить системному администратору. Риск — вся логика безопасности должна быть описана правилами на стороне Firebase, потому что промежуточного сервера, который бы проверял каждый запрос, просто нет. Клиент стучится в базу напрямую — и единственная стена между ним и чужими данными это правила, которые написал ты.

Для сравнения: в Supabase картина похожая — приложение тоже обращается напрямую к сервису, без твоего сервера посередине, — но «языком разговора» там служат SQL-запросы, а стеной выступают RLS-политики в самой базе, которые ты уже видел на курсе.

Есть ли бесплатный тариф

Да, и он щедрый. Бесплатный тариф Spark позволяет создать проект, подключить Firestore, Authentication, Storage и Hosting и спокойно разрабатывать и тестировать приложение без банковской карты и без оплаты вообще. Для учебного проекта, прототипа и первых пользователей его обычно достаточно с запасом.

Когда нагрузка вырастает — много пользователей, много чтений и записей в базу, большие файлы, исходящий трафик, — переходишь на тариф Blaze с оплатой по факту использования: платишь только за то, что реально потребил. Точные цифры лимитов и цены меняются, поэтому актуальные условия всегда смотри на официальном сайте в разделе тарифов: firebase.google.com/pricing — там же есть калькулятор для прикидки расходов.

Важный нюанс, который новички узнают поздно: на бесплатном тарифе есть суточные лимиты операций. Если учебное приложение вдруг «выстрелит» и на него зайдёт неожиданно много людей, оно просто перестанет отвечать до конца суток, а не выставит тебе огромный счёт. Для новичка это скорее защита, чем проблема. А вот на платном тарифе стоит сразу настроить бюджетные оповещения, чтобы расходы не стали сюрпризом, — такая привычка полезна для любого облака.

Ограничения, о которых стоит знать заранее

Честная статья — та, где есть и минусы. Вот они, без сглаживания:

Миграция — боль. Перенести данные с NoSQL Firestore на реляционную базу позже сложнее, чем начать сразу с Postgres или Supabase. Структуры принципиально разные, готовых «кнопок переезда» не существует. Поэтому выбор стоит делать осознанно на старте, а не «как получится».

Сложные выборки неудобны. Запросы со многими связями — «дай мне данные из пяти таблиц сразу, отсортированные и отфильтрованные» — без SQL превращаются в ручную подготовку дублирующих документов. Это рабочий, но неприятный паттерн, и он дорожает с каждой новой выборкой.

Привязка к одному вендору. Firebase — только облако Google. Развернуть его у себя нельзя, сменить провайдера без переписывания приложения нельзя, договориться об индивидуальных условиях, как с маленьким хостером, — тоже нельзя.

Правила безопасности легко настроить неправильно. Раз сервера нет, база видна из приложения напрямую, и защита — это текстовые правила, которые пишешь ты. Ошибся в одном правиле — и чужие данные могут стать доступны всем. На курсе похожую тему мы разбирали для Supabase в статье про RLS-политики — принцип «не доверяй клиенту» одинаков для обеих платформ.

Доступность из России. Сервисы Google могут работать из РФ нестабильно или требовать дополнительной настройки доступа — как и большинство зарубежных инструментов, о которых мы говорим на курсе. Проверяй доступность до того, как строить на платформе боевой проект, а не после месяца разработки.

Честный вывод

Firebase — хороший вариант для мобильных приложений с простой структурой данных и упором на push-уведомления и встроенную аналитику: в этой нише он силён как никто другой, и конкурентов по удобству у него почти нет. Для веб-проектов со сложной логикой и связанными таблицами удобнее уже разобранный на курсе Supabase — SQL, RLS-политики и возможность развернуть всё на своём сервере перевешивают удобство «коробки от Google». Если сомневаешься — начинай с Supabase: по нему у тебя есть рабочие примеры, готовые политики и понимание, как всё устроено. А Firebase запомни как инструмент «на вырост» — к тому моменту, когда решишься на мобильное приложение, ты уже будешь точно понимать, что именно от него нужно.

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

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

1. Выпиши свои данные. Открой заметки и перечисли, что будет хранить приложение: игроки, рекорды, покупки, файлы. Теперь нарисуй стрелки: рекорд принадлежит игроку, покупка относится к игроку и к товару. Стрелок много и они пересекаются — это реляционная модель, тебе к Supabase. Стрелок почти нет, данные — самостоятельные «карточки» — Firestore справится.
2. Ответь на вопрос про платформу. Приложение в первую очередь мобильное, со сторами, пушами и аналитикой? Это сильный аргумент за Firebase. Веб-приложение в браузере? Supabase ляжет естественнее.
3. Проверь доступ из своей сети. Зайди в Firebase console и в консоль Supabase с того интернета, из которого будешь работать. Сервис, до которого ты не можешь стабильно достучаться, не подходит независимо от его достоинств.
4. Спроси ИИ-ассистента обеими формулировками. Попроси набросать схему данных «под Postgres» и «под Firestore» для твоего проекта и сравни, какая выглядит проще. На маленьком примере разница подходов видна как на ладони.
5. Прикинь будущие вопросы к данным. «Топ-10 за неделю», «все покупки игрока», «кто побил мой рекорд» — если таких вопросов много и они комбинируются, SQL сэкономит тебе нервы. Если данные в основном «записал — прочитал», разницы ты не почувствуешь.

Если после чек-листа оба варианта выглядят одинаково — берите тот, по которому у тебя есть готовые примеры и поддержка. Для ученика курса это Supabase: его мы разобрали до уровня рабочего кода, и застряв, ты всегда можешь вернуться к статьям и свериться.

Частые вопросы

Firebase и Firestore — это одно и то же?

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

Firebase бесплатный или нет?

И да, и нет. Тариф Spark полностью бесплатный и подходит для разработки и небольших проектов. За большие нагрузки нужен тариф Blaze с оплатой по факту использования. Точные лимиты и цены смотри на официальном сайте — они периодически меняются, и доверять стоит только первоисточнику. Главная ловушка платного тарифа — не цена сама по себе, а её непредсказуемость при оплате «за факт»: ошибка в коде, которая читает базу в бесконечном цикле, способна накрутить счёт за часы. Поэтому правило простое: как только переходишь на Blaze, первым делом настраиваешь бюджетные оповещения.

Можно ли использовать Firebase и Supabase в одном проекте?

Технически можно — например, базу держать в Supabase, а push-уведомления слать через Firebase Cloud Messaging. Но для первого проекта это лишняя сложность: два аккаунта, два SDK, два набора правил безопасности. Выбери что-то одно и доведи проект до работающего состояния.

Что лучше для «Змейки» и учебных проектов курса?

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

Сложно ли потом переехать с Firebase на Supabase?

Сложно. Структуры данных принципиально разные: документы против таблиц со связями. Переезд означает перепроектирование базы, переписывание запросов и правил безопасности — по сути, новый проект. Поэтому выбирай осознанно на старте, пока переделывать нечего.

Нужен ли свой сервер, если есть Firebase?

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

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