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

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

Кейс Supabase — это ровно про это.
Контекст: команде нужен был backend, где можно быстро поднять авторизацию, базу, API и не зависеть от закрытой платформы.
Действие: взяли открытый стек на SQL вместо очередного “удобного, но чужого” сервиса. Получили Postgres, автогенерацию API, auth и нормальную работу с данными без ручного зоопарка.
Результат: меньше времени на инфраструктуру, больше контроля над схемой и данными. Для продукта это не «модно», а снижает риск, что тебя завтра зажмут тарифами или урежут функционал.

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

Вывод простой: выбирай не самый “удобный” сервис, а тот, где у тебя остаётся контроль над данными и процессом. 🚀