Convex хорош, пока вы не пытаетесь засунуть в него чужую архитектуру

Convex хорош, пока вы не пытаетесь засунуть в него чужую архитектуру

Convex — это backend-as-a-service с реактивными запросами и встроенной синхронизацией. Он удобен там, где нужно быстро собрать продукт: auth, БД, функции, подписки на изменения, realtime без ручной сборки инфраструктуры.

Типичная ошибка — использовать его как «ещё одну базу». В Convex лучше сразу проектировать домен вокруг функций и запросов, а не вокруг толстого ORM-слоя. Если у вас много сложных JOIN, отчётов и batch-обработки, проверьте заранее, не упираетесь ли вы в модель данных раньше, чем получите пользу от realtime.

На что смотреть перед стартом:
— как будут выглядеть права доступа на уровне функций;
— где живут тяжёлые вычисления и фоновые задачи;
— нужна ли вам полная переносимость схемы и запросов;
— сможете ли вы жить без ручного контроля над каждым SQL-скриптом.

По деньгам логика простая: free tier годится для прототипа и внутреннего инструмента, а в проде счёт растёт вместе с нагрузкой на запросы и хранение. Поэтому Convex выгоднее всего там, где важнее скорость разработки и меньше потребность в тонкой оптимизации базы.

Если проекту нужна быстрая синхронизация состояния и минимум DevOps — Convex часто закрывает задачу лучше «самосборного» стека. Если же ядро продукта — сложная аналитика и тяжёлый SQL, начинайте с проверки ограничений, а не с лендинга.