Convex хорош, пока вы строите продукт на событиях и синхронной логике

Convex хорош, пока вы строите продукт на событиях и синхронной логике

Convex часто берут как «backend без боли»: база, функции, подписки на изменения и realtime в одном месте. Для MVP это удобно, потому что не нужно сразу собирать отдельные куски из Postgres, websocket-слоя и очередей.

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

Перед стартом проверьте три вещи: — сможете ли вы жить в его query-модели без привычного SQL; — как выглядит выход из сервиса, если понадобится перенос данных; — кто в команде будет владеть схемой и серверной логикой, когда проект вырастет. Самая частая ошибка — считать Convex заменой любой backend-инфраструктуре. Это не так.

Есть наблюдение которое стоит проверить: Convex лучше всего заходит, когда продукту важны скорость итераций и live-обновления UI, а не «идеальная» архитектура с первого дня. Для внутреннего инструмента, SaaS-дашборда или коллаборативного интерфейса он часто экономит недели.

Итог простой: если вам нужен быстрый full-stack старт и realtime «из коробки» — Convex имеет смысл. Если уже сейчас видите SQL-heavy домен, заранее проектируйте путь миграции, а не надеетесь на него позже.