Convex берут не за хайп, а чтобы не собирать backend из пяти сервисов

Convex берут не за хайп, а чтобы не собирать backend из пяти сервисов

Convex — это backend с БД, API и реактивной моделью данных в одном месте. Для MVP и внутренних продуктов он удобен, когда нужно быстро поднять авторизацию, хранение сущностей и обновление UI без ручного polling.

Но ловушка простая: Convex хорошо выглядит, пока логика остаётся «CRUD + подписки». Как только появляются сложные отчёты, тяжёлые джобы, нестандартные интеграции или жёсткие требования к схеме, начинаются компромиссы. Проверяйте заранее:
• можно ли выразить ваши запросы без костылей;
• как будет жить миграция схемы;
• где исполняются фоновые задачи;
• что случится, если часть логики придётся вынести наружу.

По опыту, Convex чаще выигрывает у связки «Postgres + realtime + отдельный backend», когда команда маленькая и важна скорость сборки. Но если проект уже завязан на SQL-экосистему, аналитические запросы и внешние инструменты, цена удобства может стать слишком высокой.

Есть хорошее правило: сначала описать данные и 3-5 ключевых сценариев, потом проверить, укладываются ли они в модель сервиса. Если да — Convex экономит недели. Если нет — лучше узнать это до того, как в коде появится половина продукта.