Решение о ремонте бэкенда Supabase

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

Проверьте пять факторов: сложность запросов, разрастание RLS, зависимость от Edge Functions, обязательные требования и прогноз расходов. Ни один фактор не дает ответа сам по себе. Сложный запрос может работать безупречно. Пятьдесят узких политик иногда понятнее пяти расплывчатых. Низкий счет за хостинг может скрывать дорогую ручную работу по восстановлению. Нужно выяснить, можно ли устранить каждую трудность на месте и подойдет ли отремонтированная система для ожидаемой нагрузки в ближайшие два года.

Исправляйте дефекты, пока архитектура соответствует продукту

Ремонт предпочтительнее, когда исходные границы бэкенда по-прежнему соответствуют продукту. Если PostgreSQL остается разумным основным хранилищем, прямой доступ из клиента все еще подходит приложению, а Supabase Auth, Storage или Realtime отвечают реальным требованиям, смена платформы заменит известные дефекты неизвестными.

Классифицируйте каждую жалобу до обсуждения новой платформы. Есть четыре группы: дефект реализации, отсутствие эксплуатационной дисциплины, несовместимость архитектуры или внешнее требование. Отсутствующий внешний ключ, раскрытый секрет сервисной роли и неиндексированное условие политики относятся к дефектам реализации. Изменения схемы только через рабочую панель говорят об отсутствии дисциплины. Процесс с долгими и тяжелыми вычислениями на CPU может не подходить для Edge Functions. Условие договора о регионе размещения или аудиторском контроле, которого нет в выбранном тарифе, относится к внешним требованиям.

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

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

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

Сложность запросов оценивают по планам, а не по мнениям

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

Начните с данных о нагрузке. Документация Supabase рекомендует pg_stat_statements для поиска частых и дорогих запросов. Соберите число вызовов, общее и среднее время выполнения, строки и нормализованный запрос. Не сортируйте только по среднему времени. Запрос на 40 миллисекунд, выполненный миллион раз, может потреблять больше ресурсов, чем двухсекундный отчет, который открывают дважды в день.

Этот запрос дает полезную исходную выборку:

select
  queryid,
  calls,
  round(total_exec_time::numeric, 1) as total_ms,
  round(mean_exec_time::numeric, 1) as mean_ms,
  rows,
  left(query, 180) as sample
from pg_stat_statements
where calls >= 20
order by total_exec_time desc
limit 25;

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

Для запросов, которые создают основную задержку или отнимают большую часть времени базы, выполните EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) на безопасных репрезентативных данных. ANALYZE запускает запрос, поэтому для записи используйте транзакцию с возможностью отката и не выполняйте команду вслепую в рабочей среде. Ищите последовательное сканирование больших отношений, серьезные расхождения между расчетным и фактическим числом строк, многократные циклы, чтение с диска и сортировки с выходом за доступную память. Эти признаки указывают на нужные индексы, новые условия, более точную статистику, более узкую выборку или другую модель данных.

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

Не путайте число запросов к API со сложностью SQL. Фронтенд, созданный ИИ, часто получает список, а затем отдельно запрашивает связанные данные для каждой строки. База выполняет простые запросы, но страница ждет многочисленных сетевых обменов. Объединение доступа в представлении, RPC-функции или одном серверном endpoint относится к ремонту. Перенос неизменного шаблона лишь меняет место, где вы платите за задержку.

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

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

Разрастание RLS измеряют поведением

Разрастание RLS становится аргументом за миграцию, когда никто не может надежно предсказать и проверить, кто вправе читать и менять каждую строку. Само число политик почти ничего не говорит. Большой набор узких политик может быть безопаснее одной компактной политики со вложенными проверками членства и изменяемыми claims JWT.

Получите перечень политик из базы, а не из схемы:

select
  schemaname,
  tablename,
  policyname,
  roles,
  cmd,
  permissive,
  qual,
  with_check
from pg_policies
order by schemaname, tablename, cmd, policyname;

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

Руководство Supabase по RLS проводит важное различие, которое часто пропускают созданные приложения. Пользователи могут менять raw_user_meta_data, поэтому хранить там сведения для авторизации небезопасно. raw_app_meta_data пользователь изменить не может, и там допустимо хранить сведения для доступа, хотя содержимое JWT может устареть до обновления токена. Это не мелочь в названии. Если поместить роль не в тот claim, пользователь сможет выдать права самому себе.

Исправляйте производительность после корректности. Индексируйте столбцы из условий политик. Если семантика допускает, скалярный подзапрос вокруг auth.uid() позволяет планировщику создать начальный план и не вычислять функцию для каждой строки. Сохраняйте явные фильтры в запросах приложения, даже когда политика уже задает ту же границу арендатора: фильтр помогает выбрать более узкий путь. Эти приемы не исправят модель авторизации, которую команда не умеет описать.

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

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

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

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

Зависимость от Edge Functions определяет масштаб переноса

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

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

Supabase описывает Edge Functions как функции TypeScript в совместимой с Deno среде. Это дает коду некоторую переносимость, но окружающее поведение все равно нужно воспроизвести: маршрутизацию шлюза, обработку JWT, секреты окружения, плановые вызовы, передачу журналов, развертывание и выполнение в регионах. Фраза «код написан на TypeScript» сообщает полезный факт, но не заменяет план миграции.

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

Миграция становится привлекательной, когда ограничение среды регулярно мешает обычной нагрузке, а не редкому дефекту. Обработка изображений, преобразование крупных документов, долгие задачи ИИ, тяжелый экспорт и длительные процессы часто требуют workers с управляемой параллельностью, постоянных очередей и явного состояния повторов. Можно оставить PostgreSQL и Auth в Supabase, перенеся только такие задачи. Частичная миграция часто снимает ограничение без замены базы.

Оценивайте перенос по зависимостям, а не по числу файлов. Платежный вебхук на 80 строк с незадокументированной обработкой повторов может быть рискованнее двадцати endpoint только для чтения. Для каждой функции нужен контрактный тест, который отправляет одинаковый запрос старой и новой реализации, нормализует созданные провайдером поля и сравнивает статус, тело, последствия в базе и исходящие вызовы. Без такого стенда команда узнает о смысловых различиях от клиентов.

Обязательные требования могут перевесить техническое удобство

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

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

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

Резервные копии требуют особого внимания. В документации Supabase сказано, что резервные копии базы не включают объекты из Storage API, а содержат только их метаданные. Восстановление базы не вернет удаленный объект. Если ваш план предполагает откат того и другого одной кнопкой, он ошибочен. Исправьте его отдельной защитой объектов и тренировкой восстановления либо выберите архитектуру с подходящими средствами восстановления.

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

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

Прогноз расходов включает людей и риск перехода

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

Моделируйте расходы по причинам нагрузки. Учитывайте активных пользователей в месяц, если они влияют на аутентификацию, рост вычислений и хранилища базы, исходящий трафик по источнику и получателю, сообщения Realtime и пик подключений, объем и операции Storage, вызовы Edge Functions, объем и срок хранения логов, резервное копирование и восстановление, поддержку и обязательные дополнения тарифа. В момент решения возьмите актуальные цены обоих поставщиков. Запишите каждую цену и включенную квоту в таблицу допущений с датой, потому что тарифы меняются.

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

monthly platform cost =
  base plans
  + database compute and storage
  + network egress
  + authentication usage
  + realtime usage
  + function usage
  + logs, backups, and support

monthly operating cost =
  engineering hours
  + incident response
  + security and compliance work
  + vendor management

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

В стоимость перехода входят параллельные среды, копирование данных и объектов, сбор изменений при необходимости, двойная запись при ее выборе, контрактные тесты, обновление клиентов, наблюдаемость, проверка безопасности, поддержка переключения и возможность отката. Добавьте диапазон потерь выручки или договорных рисков из-за простоя и несогласованных данных, а не придумывайте точное число. Миграция с экономией в несколько сотен в месяц может окупаться годами.

Рассчитайте месяц окупаемости:

break_even_month =
  transition_cost /
  (repaired_monthly_cost - migrated_monthly_cost)

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

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

Балльная оценка раскрывает слабые допущения

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

Оцените каждый фактор от 0 до 3 отдельно для ремонта и миграции. Ноль означает, что вариант не выполняет требование. Три означает выполнение с подтвержденными доказательствами. Сделайте безопасность и обязательные требования проходными условиями: если вариант не выполняет обязательный контроль, итоговая сумма его не спасет.

Используйте следующие факторы:

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

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

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

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

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

Переключайтесь только с проверенным откатом

Решение о миграции не готово, пока команда не опишет перенос данных, проверку, переключение и откат. «Экспортировать и импортировать PostgreSQL» охватывает лишь часть бэкенда Supabase.

Составьте перечень схем базы, расширений, ролей, политик RLS, функций, триггеров, плановых задач, пользователей Auth и связей идентичности, объектов и метаданных Storage, подписок Realtime, Edge Functions, секретов, регистраций вебхуков, DNS и всех настроек клиентов. Решите, что переносится, что остается и что удаляется. По возможности сохраните стабильные идентификаторы пользователей или явно сопоставьте их, потому что от них часто зависят строки авторизации и владения.

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

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

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

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

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

Storage тоже требует двух проверок. Сначала сравните список объектов, размер в байтах, тип содержимого и контрольную сумму. Затем проверьте доступ так, как это делает приложение, включая подписанный доступ, публичные объекты, замену и удаление. Строки базы могут указывать на нескопированные объекты, а скопированные объекты могут стать публичными из-за нового правила bucket. Храните журналы переноса достаточно долго, чтобы расследовать обращение клиента после переключения.

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

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