Skip to content
RiverCore
Convex привлёк $57 млн на фоне проблем с повреждением данных в AI-приложениях
AI generated codedatabase corruptionbackend engineeringAI code corrupts database integrityConvex Series B Insight Partners

Convex привлёк $57 млн на фоне проблем с повреждением данных в AI-приложениях

3 сен 20266 мин. чтенияAlex Drover

Любой, кто отлаживал состояние гонки в три часа ночи, знает, как выглядит скрытое повреждение данных: приложение работает нормально, дашборды зелёные, а потом в поддержку приходит тикет с балансом, которого не должно существовать. Convex только что привлёк инвестиции, сделав ставку на то, что этот сценарий провала вот-вот станет стандартным для backend'ов, создаваемых с помощью ИИ. Позиционирование агрессивное, а цифры говорят сами за себя.

Что произошло

Convex закрыл раунд Series B на $57 миллионов под руководством Insight Partners — к нему присоединились Etna Labs, а предыдущие инвесторы a16z и Spark Capital продолжили участие, как сообщил Ventureburn 4 августа 2026 года. Таким образом, общий объём привлечённого финансирования достиг $110,5 миллиона с момента основания компании в 2021 году бывшими инженерами инфраструктуры Dropbox в Сан-Франциско.

Показатели роста способны напугать конкурентов. По словам Convex, его платформа уже обеспечивает работу почти двух миллионов приложений, её используют около 500 000 разработчиков, а еженедельное число загрузок npm превышает 1,2 миллиона. Среди клиентов — OpenAI, Tripadvisor, Solana, Zapier и Reducto. Это не список дизайн-партнёров. Это реальная производственная нагрузка.

Стратегически важно то, как позиционируется этот раунд. Convex явно представляет себя как AI-native backend, а не универсальный BaaS. В подтверждение этого компания опубликовала результаты внутреннего тестирования: 90% AI-приложений, работающих на традиционных базах данных, столкнулись с повреждением данных в реальных условиях, тогда как те же приложения, построенные на Convex, завершили тесты без сбоев. Именно этот тезис купил Insight Partners.

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

Техническая составляющая

Стек Convex объединяет то, что большинство команд сейчас собирают вручную: базу данных, функции, воркфлоу, поиск, синхронизацию, аутентификацию, файловое хранилище и функции retrieval-augmented generation. Всё это доступно через TypeScript со сквозной типобезопасностью, ACID-транзакциями и real-time подписками. В обычном стеке для достижения того же результата пришлось бы связывать Postgres, очередь, поисковый движок, провайдера аутентификации, объектное хранилище и слой WebSocket. Шесть вендоров, шесть точек отказа, шесть наборов учётных данных.

Цифра в 90% случаев повреждения данных — это суть технического аргумента, поэтому стоит интерпретировать её честно. AI-агенты охотно пишут многошаговые операции с базой данных без транзакций. Они охотно игнорируют ограничения уникальности, пропускают оптимистичную блокировку и маскируют состояния гонки повторными попытками. На традиционном стеке ни один из этих сбоев не проявляется громко. Они обнаруживаются в бухгалтерских отчётах через две недели.

Ответ Convex — сделать ACID-транзакции моделью выполнения по умолчанию для своих функций, а не опцией, о которой разработчик (или агент) должен помнить. Если ваша сгенерированная функция обращается к состоянию, она выполняется внутри транзакции. Система типов передаёт информацию о схеме от базы данных к клиенту, поэтому агент, «галлюцинирующий» поле, получает ошибку компиляции, а не повреждённую строку. Real-time подписки означают, что клиент видит зафиксированное состояние, а не устаревший кэш, который агент забыл инвалидировать.

Моё мнение: интересное инженерное утверждение здесь не «мы быстрее Postgres». Оно звучит так: «мы убрали острые углы, о которые режется AI-генерированный код». Это другая продуктовая категория. У неё есть и реальная цена. Вы принимаете привязку к единственному вендору на всём уровне backend и доверяете операционной зрелости Convex для рабочих нагрузок, которые раньше лежали на хорошо изученных open-source примитивах. Производственные инциденты, которые я наблюдал у операторов с полностью управляемыми стеками, как правило, короче, но сложнее для анализа первопричин, потому что вы не можете подключить отладчик к чужому уровню хранения.

Кто окажется под ударом

Этот раунд затрагивает три группы. Во-первых, классические BaaS-игроки. Firebase и Supabase были рефлекторным ответом для команд, желавших избежать сложностей backend. Теперь Convex располагает $110,5 миллиона и дифференцированным нарративом, нацеленным именно на наиболее быстрорастущую когорту новых проектов — разработчиков, работающих с AI-агентами. Это не та борьба, которую игроки рынка могут игнорировать.

Во-вторых, платформенные команды внутри крупных компаний. Если ваша внутренняя платформа разработчика — это тщательно подобранный набор из Postgres, Redis, Kafka и сервиса аутентификации, вам теперь придётся отвечать на вопрос от продуктовой инженерии: почему мы не можем просто использовать Convex? Честный ответ обычно касается соответствия требованиям, размещения данных и уже сделанных инвестиций в observability. Но этот ответ нужно зафиксировать письменно, потому что его будут задавать снова и снова в течение следующих 12 месяцев.

В-третьих, и это важно для читателей из iGaming и fintech: любая команда, которая сейчас позволяет AI-ассистентам писать продакшн-код доступа к данным против схемы без строгих инвариантов. Неудобный вывод: если внутренняя цифра Convex в 90% хотя бы приблизительно верна, многие компании, которые с энтузиазмом мёржили output Copilot в свои платёжные сервисы и кошельки, имеют скрытую проблему повреждения данных, которую ещё не обнаружили. В регулируемых вертикалях такие проблемы выявляются через отчёты о сверке, а не через stack trace.

Следующие 90 дней для конкурирующих вендоров предсказуемы. Ожидайте, что Supabase и PlanetScale опубликуют собственное «AI-safe» позиционирование. Ожидайте, что как минимум один крупный облачный провайдер анонсирует управляемый транзакционный пакет. Ожидайте волну постов о возвращении ACID в моду. Нарратив изменился, а $57 миллионов — это очень много нарратива.

Руководство для инженерных команд

Вам не нужно мигрировать на Convex в этом квартале. Вам нужно серьёзно отнестись к базовой проблеме. Вот что стоит сделать в ближайшие две недели.

Проведите аудит кодовых путей, созданных с помощью ИИ, на предмет транзакционных границ. Используйте grep для поиска многострочных операций записи, не обёрнутых в транзакцию. Если вы работаете на Postgres, это работа на выходные, и она дешевле, чем инцидент со сверкой. Добавьте интеграционные тесты, проверяющие инварианты под конкурентной нагрузкой. AI-сгенерированный код проходит юнит-тесты. Он падает под конкурентным доступом.

Инструментируйте ваш уровень данных с помощью правильной трассировки, чтобы реально видеть, когда ограничения нарушаются в продакшне. OpenTelemetry-спаны на каждый вызов базы данных почти ничего не стоят и превращают «скрытое повреждение» в «громкое оповещение». Если вы не можете ответить на вопрос «сколько нарушений ограничений у нас было на прошлой неделе», вы летите вслепую.

Опробуйте Convex на некритичном greenfield-сервисе, прежде чем рассматривать его для чего-либо регулируемого. Два миллиона приложений — это впечатляет, но список из пяти названных клиентов говорит о том, что охват закалённых сценариев всё ещё уже, чем у десятилетнего развёртывания Postgres. Это не критика — это кривая зрелости.

Наконец, введите письменную политику, определяющую, что AI-агентам разрешено создавать без надзора. Запросы только на чтение — да. Миграции схем — нет. Всё, что касается денег, — человеческая проверка. Скучно, но 500 000 разработчиков, использующих AI-native инструменты, означают, что эта политика теперь является несущим элементом вашей риск-позиции.

Ключевые выводы

  • Series B Convex на $57 млн, доведший общее финансирование до $110,5 млн, — это ставка на то, что AI-генерируемые backend'ы нуждаются в других примитивах, чем написанные людьми.
  • Заявленные 90% повреждения данных на традиционных базах — маркетинговая цифра, но базовый сценарий провала (агенты, пропускающие транзакции) реален и требует аудита.
  • Почти два миллиона приложений и 1,2 миллиона еженедельных загрузок npm означают, что Convex вышел за рамки стадии дизайн-партнёров и достиг реального производственного масштаба.
  • Single-vendor backend'ы меняют боль интеграции на lock-in и операционную непрозрачность. Подходит для greenfield, сложнее обосновать в регулируемых вертикалях.
  • Независимо от стека, каждая инженерная команда должна в этом месяце провести аудит AI-ассистированного кода на предмет отсутствующих транзакционных границ.

Часто задаваемые вопросы

В: Чем Convex принципиально отличается от Firebase или Supabase?

Convex объединяет базу данных, функции, воркфлоу, поиск, аутентификацию, файловое хранилище и функции RAG в одну платформу с ACID-транзакциями и сквозной TypeScript-типобезопасностью по умолчанию. Суть в том, что AI-генерированный код реже даёт сбои, поскольку платформа обеспечивает согласованность, о которой агент забыл позаботиться.

В: Заслуживает ли доверия цифра в 90% повреждения данных ИИ?

Это внутренний тест Convex, поэтому относитесь к нему как к маркетинговому ориентиру, а не независимому исследованию. При этом базовая закономерность (AI-агенты, пишущие нетранзакционные многошаговые операции с базой данных) хорошо известна всем, кто проверяет Copilot output в продакшн-репозиториях.

В: Стоит ли fintech или iGaming-команде мигрировать на Convex?

Не на основании одного лишь раунда финансирования. Опробуйте его на некритичном greenfield-сервисе, проверьте соответствие требованиям и размещение данных, а регулируемые рабочие нагрузки оставьте на инфраструктуре, которую ваша команда может отлаживать на уровне хранения. Интересный вопрос в том, достаточно ли транзакционные дефолты Convex снижают частоту AI-ассистированных багов, чтобы оправдать lock-in.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// ПОХОЖИЕ СТАТЬИ
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU