PlanetScale удобен, пока вы не упираетесь в миграции и join-heavy запросы

Если вам нужен MySQL без боли с руками в проде, PlanetScale закрывает базовую задачу: быстрый старт, ветки схемы, безопасные deploy requests, понятная изоляция изменений. Для соло-проектов и небольших команд это часто лучше, чем сразу собирать собственный кластер и режимы отказоустойчивости.

Но есть наблюдение которое стоит проверить: сервис хорошо ложится на приложения, где модель данных заранее продумана под чтение по ключу и простые выборки. Как только начинаются сложные join’ы, отчёты, агрегации и «давайте ещё один индекс», вы чаще думаете не о продукте, а о том, как обойти ограничения схемы и соединений.

Перед выбором проверьте три вещи: — сможете ли вы жить без привычных транзакционных паттернов вокруг схемы; — не придётся ли вынести аналитические запросы в отдельный слой; — готовы ли вы к цене ошибки в схеме, если команда часто меняет модель данных. Для веб-агентств это особенно важно: клиентский проект с хаотичными правками быстро превращает удобный managed MySQL в источник компромиссов.

Если проект растёт в сторону сложной аналитики, многошаговых транзакций и плотных join’ов, лучше закладывать миграцию заранее. PlanetScale хорош как ускоритель старта, но его сильная сторона — не универсальная база, а аккуратный MySQL для команд, которые умеют держать схему простой.

Railway удобен, пока проект маленький: дальше начинает решать дисциплина деплоя

Railway любят за низкий порог входа: поднял сервис, подключил БД, накинул переменные — и поехали. Но это не «магический хостинг», а платформа, где быстро всплывают слабые места проекта: неявные зависимости, забытые миграции, фоновые задачи в web-процессе.

За неделю в репах обычно видно одно и то же:
— всё держится на одном контейнере, который делает и API, и воркеры, и cron;
— healthcheck есть, а реального readiness нет;
— миграции запускаются вручную и ломают релизы;
— логи есть, но без нормальной корреляции с запросами.

Если нужен Railway надолго, делите приложение на минимум 3 роли: web, worker, scheduler. Базу держите отдельно от кода, а секреты — только в переменных окружения. И ещё: любой deploy должен быть повторяемым без участия человека. Если сборка или старт требуют «докинуть руками», значит схема уже хрупкая.

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

Итог простой: Railway — отличный старт для MVP и аккуратного продакшена, если архитектура разнесена по ролям. Чем раньше вы отделите web от worker и миграции от ручного запуска, тем меньше сюрпризов будет при росте.

Convex: когда backend хочется убрать в сторону, а не строить заново

Convex — это backend с реактивной моделью данных: пишешь функции, а клиент получает обновления без ручного polling и лишнего glue-кода. Для прототипов, админок, внутренних CRM и realtime-фич это часто быстрее, чем собирать связку API + WebSocket + отдельная синхронизация.

Что обычно нравится:
— данные и запросы живут рядом, без отдельного слоя ORM, если задача простая;
— подписки на изменения нативные, поэтому чаты, дашборды и очереди задач делаются без боли;
— удобно для команд, где фронтенд важнее сложной доменной логики.

Но есть и типовые ловушки:
— если у вас много сложных SQL-отчётов, Convex не заменяет полноценную БД-аналитику;
— при переносе с классического бэкенда придётся переосмыслить архитектуру, а не просто «подключить сервис»;
— vendor lock-in здесь реальный: сначала оцените, насколько вам важны экспорт схемы, данных и логики.

Хорошая проверка перед стартом: можно ли ваш продукт описать как «много CRUD + realtime + простая логика»? Если да, Convex даст скорость. Если нет — он всё равно может подойти как слой для части приложения, но не как единственный фундамент.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

Convex: когда BaaS нужен не ради базы, а ради сложной бизнес-логики

Convex часто берут как «ещё один backend без сервера», но его сильная сторона не в том, чтобы просто хранить записи. Он полезен там, где данные и действия должны жить рядом: подписки, чаты, уведомления, очереди, правила доступа, реактивные обновления в UI.

Главный чек перед стартом:
— если у вас CRUD и пара таблиц, Convex может быть лишним;
— если нужен realtime без ручной склейки WebSocket, это уже его территория;
— если логика должна выполняться на сервере и сразу триггерить обновление клиента, Convex экономит много glue-кода.

Есть наблюдение которое стоит проверить: Convex удобнее всего ложится на продукты, где фронтенд и бэкенд пишутся одной командой. Меньше контекстных переключений, меньше отдельных API-контрактов, быстрее прототип. Но если проект уже живёт на сложной микросервисной схеме, интеграция может оказаться дороже, чем новый сервис.

Отдельно смотрите на vendor lock-in. Чем больше вы завязываете правила, запросы и реактивность на специфичный слой платформы, тем дороже миграция. Для старта это нормально, если заранее держать в голове простой план выхода: где лежат критичные данные, как их экспортировать, что будет без realtime.

Если нужен не «ещё один Postgres», а быстрый путь к серверной логике, которая сразу отражается в интерфейсе, Convex попадает в точку. Если же вам важнее переносимость и стандартный стек, лучше не ускоряться раньше времени.