Стоит ли бэкенду, созданному ИИ, уходить с Firebase?

Приложению пора уходить с Firebase, когда модель данных, правила авторизации или серверные процессы стали сложнее самого продукта. Не стоит переносить систему лишь потому, что команда слышала о большей серьезности Postgres. Поспешная переработка способна заменить прежние ограничения сбоем, потерянными учетными записями и месяцами рассинхронизации двух систем.

Для большинства команд, которым стало тесно в Firestore, Supabase будет практичным промежуточным вариантом: реляционные данные, SQL, управляемая аутентификация, хранение файлов, функции и генерируемый API в одном сервисе. Обычный управляемый Postgres дает опытной команде больше контроля и навязывает меньше соглашений, но ей придется самостоятельно собрать аутентификацию, API, файловое хранилище, фоновые задачи, наблюдаемость и развертывание. Иногда лучше остаться на Firebase, если документная модель подходит, а команда может исправить правила и функции без постоянной борьбы с платформой.

Направление определяет ограничение, за которое вы больше не готовы платить

Выбирайте направление по тому ограничению, которое уже отнимает время разработчиков. Если никто не способен сформулировать его одним предложением, команда еще не готова к миграции. Расплывчатая жалоба «Firebase не масштабируется» ничего не диагностирует. Firestore справляется с крупной нагрузкой; выяснить нужно другое: подходят ли конкретному приложению его способы доступа и модель согласованности.

Firebase сохраняет смысл, когда клиенты в основном читают и записывают независимые документы, важна работа без сети, центральную роль играют обновления в реальном времени, а Security Rules описывают доступ без дублирования бизнес-состояния. Доводов за перенос становится больше, когда одно действие пользователя должно обновить несколько связанных записей, отчеты требуют объединения коллекций, ссылочную целостность нужно обеспечивать в базе данных либо Cloud Functions остается единственным местом, где еще понятны настоящие правила.

Supabase подходит командам, которым нужна семантика Postgres, но не хочется собирать все окружающие сервисы. Во время переноса он сокращает число решений. Это особенно полезно, если текущий код собрало ИИ-средство и достоверной карты системы нет. Соглашения Supabase одновременно задают границы: у Supabase Auth свой жизненный цикл, генерируемый API данных зависит от построчной безопасности, а функции платформы не полностью заменяют универсальный сервер приложений.

Управляемый Postgres подходит, когда команда уже выбрала веб-фреймворк, поставщика идентификации, систему фоновых заданий, хранилище и средства мониторинга. Базу данных можно переносить, но бэкенд придется проектировать и эксплуатировать самой команде. Свобода появляется только при наличии ответственного за эти решения.

До обсуждения поставщиков составьте простую таблицу. За каждое утверждение добавьте балл подходящему направлению:

Баллы не примут решение за команду. Они сделают аргументы видимыми. Любая строка, которую нельзя оценить на основе фактов, превращается в задачу для исследования до начала миграции.

Сложность миграции скрыта в поведении, а не в количестве записей

Миллион простых документов порой перенести легче, чем десять тысяч документов, смысл которых зависит от триггеров, клиентских меток времени, денормализованных счетчиков и Security Rules. Количество записей влияет на длительность копирования. Связанное поведение определяет объем проекта.

Сначала нанесите на карту все пути изменения постоянного состояния. В кодовой базе, созданной ИИ, очевидный клиент базы данных может оказаться не единственным источником записи. Код браузера способен писать прямо в Firestore, серверные маршруты могут обращаться через Admin SDK, задачи по расписанию могут исправлять счетчики, обработчики вебхуков могут менять состояние платежей, а сценарии развертывания могут создавать начальные документы. Ищите инициализацию SDK, названия коллекций, вызываемые функции, обращения к файловым хранилищам и переменные среды. Затем сопоставьте карту с производственными журналами и облачной конфигурацией. Поиск по коду не найдет развернутую функцию, которую уже удалили из репозитория.

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

Разделите оценку на четыре группы: преобразование данных, смена системы идентификации, замена процессов и интеграция клиента. В преобразование входят выравнивание вложенных документов, перенос повторяющихся значений в таблицы, выбор типов и разбор потерянных ссылок. Смена идентификации охватывает хеши паролей, связанные поставщики входа, сеансы, почтовые шаблоны, адреса перенаправления и восстановление учетных записей. Замена процессов включает функции, очереди, задачи по расписанию, вебхуки и события хранилища. Интеграция клиента охватывает новые запросы, состояния загрузки, допущения об офлайн-работе, обработку ошибок и проверки авторизации.

Отдельный файл инвентаризации позволяет проверить оценку. Это может быть простой JSON рядом с кодом миграции:

{
  "source": "firestore",
  "collections": {
    "orders": {
      "writers": ["web-checkout", "payment-webhook"],
      "readers": ["account-page", "support-console"],
      "rules": ["owner-read", "support-read"],
      "side_effects": ["send-receipt", "increment-customer-total"]
    }
  }
}

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

Экспорт Firestore дает исходные данные, а не схему Postgres

Управляемый экспорт Cloud Firestore создает в Cloud Storage файлы журнала LevelDB и метаданные. Документация Firebase описывает экспорт как данные, которые можно импортировать в другую базу Firestore либо при определенных условиях загрузить в BigQuery. Это не реляционный дамп для pg_restore и не точный снимок на момент запуска операции. Считайте его исходным материалом для контролируемого преобразования.

Для миграции нужно явно сопоставить пути документов с таблицами. Путь customers/{customerId}/orders/{orderId} уже содержит связь. В Postgres ее обычно выражает внешний ключ orders.customer_id. Массивы простых тегов можно оставить массивами. Массивы независимо меняющихся объектов обычно превращаются в дочерние строки. Поля-карты можно разложить по типизированным столбцам, если продукт выполняет по ним запросы, или сохранить в jsonb, если их структура действительно открыта. Если поместить каждый документ в jsonb, первый импорт станет проще, но слабости старой модели сохранятся.

Firestore допускает отсутствие полей и различие типов между документами. Postgres требует выбрать тип, после чего схема обеспечивает его соблюдение. Исследуйте источник до утверждения таблиц: посчитайте пропущенные поля, перечислите наблюдаемые типы, найдите повторяющиеся естественные идентификаторы и ссылки на удаленные документы. Заранее решите, что делать с каждой аномалией. Тихое преобразование, например замена неверной даты на null, позволяет завершить импорт, но переносит скрытую ошибку в рабочую систему.

Общественные инструменты миграции с Firebase на Supabase умеют преобразовать коллекции Firestore в JSON и загрузить обработанные данные, однако они не знают задуманных приложением отношений. Для управляемого Postgres часто понятнее собственные средства извлечения и загрузки. В обоих случаях преобразование должно быть детерминированным: одна исходная запись всегда дает одну и ту же строку и идентификатор. Сохраняйте столбец с исходным ID до окончания сверки.

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

create table customers (
  id uuid primary key,
  firebase_uid text unique,
  email text not null
);

create table orders (
  id uuid primary key,
  customer_id uuid not null references customers(id),
  provider_event_id text not null unique,
  status text not null check (status in ('pending', 'paid', 'cancelled')),
  created_at timestamptz not null
);

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

Аутентификацию переносят отдельно от данных приложения

Учетная запись не сводится к обычной строке. Действующий аккаунт включает учетные данные, идентификаторы у поставщиков входа, состояние проверки, сеансы, восстановление и ссылки из бизнес-данных. Перенос коллекции users не переносит Firebase Authentication, даже если у них один UID.

Firebase CLI поддерживает auth:export, а Firebase раскрывает параметры хеширования паролей для совместимого импорта. В руководстве Supabase по миграции Firebase Auth используется инструмент из двух частей: первая экспортирует пользователей Firebase в JSON, вторая импортирует их в целевую таблицу auth.users. Руководство требует сохранить параметры Firebase SCRYPT, в том числе ключ подписи, разделитель соли, число раундов и стоимость памяти. От этого зависит, смогут ли пользователи с паролями войти обычным способом или всем придется восстанавливать учетную запись.

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

Можно защитить три варианта перехода. Принудительный сброс проще всего, но увеличивает обращения в поддержку и требует продуктового решения. Массовый импорт хешей сохраняет проверку пароля, если цель поддерживает алгоритм и параметры источника. Ленивая миграция проверяет старые учетные данные при первом входе, создает или обновляет целевую идентичность и перестает обращаться к старой системе для этого пользователя. Такой способ уменьшает риск первого дня, но продлевает период, когда доступ выдают две системы.

При любом варианте создайте неизменяемую карту идентичностей до переноса бизнес-строк:

firebase_uid                         postgres_user_id
n7Yx...                              2d99150e-3b33-4afb-9c5b-7cbd20b91a4d

Во время миграции никогда не связывайте записи по электронной почте. Люди меняют адреса, поставщики по-разному нормализуют их, а за годы импорта появляются дубликаты. Используйте исходный UID как миграционную идентичность, затем присоедините целевой ID. Проверьте отключенных и неподтвержденных пользователей, удаленные аккаунты с оставшимися данными, вход только через поставщика и восстановление. Успешный обычный вход по паролю доказывает совсем немного.

Авторизацию нужно переписать, а не перевести

Firestore Security Rules и построчная безопасность Postgres отвечают на похожие вопросы через разные модели исполнения. Механический перенос опасен. Правила Firestore оценивают запрос с учетом путей документов и предлагаемых данных. Политики Postgres фильтруют строки для операций SQL, а роли и разрешения определяют доступные вызывающей стороне объекты. Серверный код с привилегированными учетными данными способен обойти обе системы, поэтому граница доверия не менее важна, чем синтаксис политики.

Сначала опишите матрицу доступа на языке продукта. Для каждого ресурса укажите, кто может выбирать, вставлять, менять и удалять его, а также разрешенные поля и переходы состояния. Фраза «пользователь может менять свой профиль» неполна, если та же строка содержит is_admin. Фраза «владелец может менять заказ» неверна, если покупатель способен перевести status из pending в paid.

Политика Supabase для чтения собственных заказов может выглядеть так:

alter table orders enable row level security;

create policy "customers read own orders"
on orders for select
to authenticated
using (customer_id = auth.uid());

Она работает, только если orders.customer_id хранит тот же UUID, который возвращает auth.uid(). Когда импортированная строка содержит текстовый UID Firebase, а новый токен содержит UUID Supabase, политика не возвращает строк. Если разработчик отключит построчную безопасность ради работающего экрана, пользователю могут открыться все строки. Поэтому карта идентичностей и схема входят в проверку авторизации.

Сам по себе управляемый Postgres не предоставляет auth.uid(). Приложение должно создать аналогичный контекст сеанса либо всегда фильтровать данные через доверенный серверный код. Многие команды выбирают второй путь: клиент вызывает API, API проверяет личность, а SQL получает идентификатор пользователя в параметре. Такую модель проще просмотреть в одной кодовой базе, но каждый endpoint обязан проверять права. Прямой доступ к базе из браузера требует более строгих ролей и тестов политик.

Проверяйте запреты, а не одни успешные операции. Для каждой роли попытайтесь прочитать строку другого клиента, поменять столбец владельца или защищенное состояние, вставить чужой ID владельца и выполнить действие через каждый публичный маршрут. Используйте те же открытые учетные данные и claims токена, что и клиент. Запрос из административной консоли ничего не доказывает об изоляции пользователей.

Пользовательские процессы определяют, достаточно ли Supabase

Обычно Supabase достаточно, если поведение можно разместить в ограничениях SQL, функциях базы, edge-функциях, задачах по расписанию, вебхуках и умеренном числе фоновых заданий. Управляемый Postgres дает более ясную конструкцию, если продукту нужны долгие worker-процессы, особые среды исполнения, сложные очереди, частные сети или контроль развертывания, который не укладывается в модель функций платформы.

Перечислите существующие Cloud Functions по типам триггеров, а не по именам файлов. HTTP-функции работают как API. Вызываемые функции связывают клиент с протоколом Firebase. Триггеры Firestore реагируют на изменение данных. Хуки аутентификации реагируют на события идентификации. Триггеры хранилища обрабатывают файлы. Функции по расписанию обслуживают систему. Для каждой категории нужно подобрать цель с подходящим поведением доставки и повторов.

Особенно внимательно отнеситесь к доставке как минимум один раз. Платежный вебхук, событие хранилища или сообщение очереди может прийти дважды, даже если обычно этого не происходит. Новый обработчик должен зарегистрировать ID события в той же транзакции, где меняет состояние. Уникальное ограничение в приведенной выше схеме превращает вторую доставку в обнаруживаемый дубликат. Флаг в памяти или строка журнала не дают такой гарантии между экземплярами.

Не переносите каждый процесс в триггер базы только потому, что Postgres умеет их выполнять. Триггеры хорошо подходят локальным инвариантам и небольшим производным изменениям в общей транзакции. Они плохо подходят для вызова сторонних API, отправки писем и медленной обработки файлов. Таким действиям нужна надежная запись задания и worker с идемпотентными повторами. База должна в одной транзакции подтвердить бизнес-изменение и поставить намерение в очередь.

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

Эксплуатационная нагрузка начинается после запуска

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

Firebase снимает большую часть администрирования базы, но команда отвечает за Security Rules, индексы, квоты, развертывание функций, неожиданные расходы, выбор региона и восстановление приложения. Supabase управляет Postgres и объединяет несколько серверных сервисов, однако команда отвечает за миграции схемы, политики строк, соединения, производительность запросов, совместимость расширений и взаимодействие компонентов. Поставщик управляемого Postgres следит за процессом базы, резервными копиями и частью обслуживания, а команда владеет уровнем API и всеми выбранными вспомогательными сервисами.

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

Сравнение расходов имеет смысл только при одинаковой нагрузке и одинаковых допущениях о сбоях. Firestore тарифицирует операции и хранилище по своей модели. Тарифы Postgres часто объединяют вычисления, а затем ограничивают соединения, память, хранилище или пропускную способность. Запрос одного реляционного агрегата нельзя сравнить с загрузкой сотен документов клиентом, а экземпляр Postgres для пиковой нагрузки нельзя сравнить с расходами простаивающего бессерверного сервиса. Воспроизведите похожие на рабочие запросы на тестовой цели и запишите задержку, затронутые строки, использование соединений и объем настройки. Не делайте выводы по пустой демонстрации.

У переносимости тоже есть уровни. SQL-таблицы проще перемещать между поставщиками Postgres, чем превращать данные Firestore в реляционную схему. Supabase Auth, метаданные хранилища, генерируемые API, политики и edge-функции все равно добавляют работу при следующей миграции. Это нормально, если сегодня сервисы экономят больше труда, чем могут потребовать завтра. Обещание «никакой привязки» скрывает зависимости приложения, которые действительно важны.

Безопасный переход оставляет одного владельца каждой записи

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

Возьмите за основу такую последовательность:

1. Заморозьте изменения схемы и перечислите всех читателей, авторов записи, функции, правила, индексы и секреты.
2. Создайте целевую схему, карту идентичностей, тесты авторизации и детерминированный импорт в изолированной среде.
3. Полностью отрепетируйте перенос из свежего экспорта, замерьте время и сверьте бизнес-факты.
4. Скопируйте последние данные, захватите изменения после начала копирования и приостановите исходные записи для финальной разницы.
5. Сначала переключите серверные источники записи, затем клиенты, следите за обеими системами и сохраняйте проверенный путь назад, пока новые целевые записи не сделают его опасным.

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

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

Опишите возврат как испытанную процедуру с крайним сроком. До начала записей в цель достаточно вернуть клиенты и отбросить целевую базу. После появления записей только в цели возврат потребует обратного преобразования или остановки записи. Укажите точное событие, закрывающее простое окно возврата. Резервная копия помогает, но не заменяет план, пока команда не восстановила ее и не измерила время.

Перед переносом бэкенда кодовой базе может потребоваться ремонт

Миграция усиливает все, чего текущее приложение не выражает явно. Сгенерированные проекты часто смешивают браузерные и серверные учетные данные, дублируют обращения к базе в компонентах, доверяют присланным клиентом ID владельца и прячут бизнес-правила в обработчиках интерфейса. Перенос вызовов на Supabase или Postgres без изменения границ перенесет и дефекты.

Начинайте миграцию только после ответа на четыре вопроса о коде. Какие модули могут обращаться к базе? Где серверная идентичность становится доверенным ID пользователя? Какой сервис владеет каждым переходом состояния? Какая среда может читать привилегированные секреты? Если ответы меняются от экрана к экрану, сначала создайте небольшую границу доступа к данным. Идеальная архитектура не требуется. Все записи должны стать видимыми и проверяемыми.

Работа с секретами требует отдельной проверки. Веб-конфигурация Firebase идентифицирует проект, а защищают его Security Rules и настройки сервисов. Учетные данные Admin SDK предоставляют привилегированный доступ. У Supabase есть открытые клиентские учетные данные для работы с построчными политиками и привилегированные серверные учетные данные, обходящие обычные ограничения. Строки подключения управляемого Postgres обычно должны находиться только на сервере, а не в браузере. Автоматическая замена часто путает эти категории, поскольку все они выглядят как переменные среды.

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

Не переносите кодовую базу, которая не проходит базовую проверку путей записи. Стабилизируйте идентичность и бизнес-инварианты, выберите самое небольшое направление с нужными возможностями и репетируйте, пока сверка не станет рутинной. Firebase, Supabase и управляемый Postgres способны поддерживать исправный продукт. Ни один из них не восполнит отсутствующее понимание ожидаемого поведения этого продукта.