Convex ломается не на старте, а когда команда путает его с обычной БД

Convex ломается не на старте, а когда команда путает его с обычной БД

Convex — это не «ещё один backend-as-a-service», а связка БД, функций и подписок на изменения. Для прототипа это удобно: меньше клея между API, state и realtime. Но если с первых дней начать проектировать как для PostgreSQL, потом больно переезжать.

Есть 3 типовые ошибки:
— тащат тяжёлые выборки в клиент и рассчитывают, что «сервер сам оптимизирует»;
— хранят в одном документе слишком много денормализованных полей;
— не закладывают границы между публичными и серверными действиями. В Convex это особенно важно: логика должна жить рядом с данными, а не размазываться по фронту.

Что проверять до старта: модели доступа, размер документов, частоту обновлений и сценарии миграции. Если у вас много аналитических запросов, сложных JOIN-логик или отчётных выгрузок, Convex может стать удобной прослойкой, но не заменой всему стеку. Для продуктового CRUD, чатов, досок, уведомлений и live-состояния он заходит заметно лучше.

Правило простое: берите Convex там, где цените скорость сборки и realtime, а не там, где уже сейчас нужна «идеальная» реляционная схема.