Skip to content
RiverCore
Supabase достигает оценки $10,5 млрд на фоне AI-разработки бэкендов
Supabase valuationSeries FpgvectorSupabase AI backend funding roundPostgres AI coding infrastructure

Supabase достигает оценки $10,5 млрд на фоне AI-разработки бэкендов

7 июн 20266 мин. чтенияAlex Drover

Каждый backend-разработчик, который в 11 вечера собирал прототип на Firebase, знает ловушку: всё взлетает быстро, а потом упираешься в запрос, который не написать. Supabase пять лет продаёт выход из этой ловушки — и инвесторы только что оплатили следующую главу. Раунд на $500 миллионов при постденежной оценке $10,5 миллиарда — это не голос за базу данных. Это голос за то, против чего будет работать AI-генерированный код в 2027 году.

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

Supabase закрыл раунд Series F на $500 миллионов при постденежной оценке $10,5 миллиарда, как сообщил Unite.AI. Раунд возглавил GIC. Список существующих инвесторов звучит как перекличка Sand Hill Road: Accel, Y Combinator, Craft, Felicis, Peak XV и Coatue вернулись снова. Stripe увеличил свою долю. Salesforce Ventures вошёл как новый инвестор.

Одновременно с финансированием Supabase выпустил Multigres v0.1 в альфа-версии — компания описывает его как масштабируемую операционную систему для Postgres. Это отдельная новость с совершенно другими последствиями, и мы к ней вернёмся.

Сам продукт принципиально не изменился. Supabase по-прежнему предлагает базу данных Postgres, аутентификацию, мгновенные API, Edge Functions, real-time подписки, хранилище и векторные эмбеддинги через pgvector. Изменился состав клиентов и профиль нагрузки. AI-инструменты для написания кода — Cursor, Claude Code и агенты в стиле Codex — теперь генерируют код приложений, который обращается к API Supabase. Питч тот же, что в 2020-м: меньше движущихся частей, больше Postgres. Но покупатель теперь не только соло-фаундер. Всё чаще это автономный агент, выбирающий инфраструктуру вместо разработчика, который не читал документацию.

Привлечение $500 миллионов при такой оценке даёт огромный запас хода. Но и фиксирует ожидания. Чтобы оправдать $10,5 миллиарда, Supabase должен вырасти из дефолтного выбора для пет-проектов до дефолтного выбора для enterprise. Этот разрыв шире, чем большинство cap table готовы признать.

Техническая анатомия

Архитектурная ставка здесь проста и стоит повторения: держать всё в Postgres. Строки приложения, идентификаторы пользователей, векторные эмбеддинги, real-time потоки изменений — всё это хранится внутри одного экземпляра Postgres, доступного через сгенерированные REST и GraphQL API плюс real-time слой.

Расширение pgvector — несущий элемент AI-истории. Оно позволяет хранить и запрашивать векторные эмбеддинги прямо в таблицах Postgres, а значит семантический поиск, рекомендательные системы, retrieval-augmented generation и AI-ассистенты могут жить рядом с записями пользователей, на которые ссылаются. Никакой второй базы данных. Никаких задач синхронизации. Никакого окна eventual consistency между «что сделал пользователь» и «что знает слой поиска». Для большинства AI-нагрузок прикладного уровня эта интеграция ценнее, чем сырая пропускная способность векторного поиска.

Edge Functions — второй столп. Это глобально распределённые серверные TypeScript-функции, предназначенные для работы близко к пользователям: обработка вебхуков, обработка входных данных, генерация эмбеддингов и вызовы сторонних API. Supabase также добавил возможности AI-инференса в Edge Functions — это сигнал, что компания рассматривает serverless-слой как часть AI-стека, а не как вспомогательный элемент.

И наконец — Multigres v0.1 альфа. Название отсылает к Vitess — системе шардирования, которая масштабировала MySQL для YouTube и затем для тысяч других команд. Supabase описывает Multigres как масштабируемую операционную систему для Postgres, направленную на хорошо известную проблему потолка: вертикальный Postgres прекрасен, пока не перестаёт быть таковым, а горизонтальный Postgres исторически превращался в кладбище недописанных форков. Альфа означает альфа. Я видел production-инциденты, когда команды принимали v0.x слои шардирования, потому что маркетинговая страница выглядела законченной. Не будьте той командой.

Моё мнение: pgvector и Edge Functions — это реальный продукт сегодня. Multigres — это стратегический флаг в земле, сигнализирующий, что Supabase намерен стать ответом, когда неизбежный Slack-тред «мы переросли наш основной сервер» появится в 2027 году.

Кто пострадает

Специализированным векторным базам данных теперь сложнее продавать. Если pgvector достаточно хорош для retrieval-augmented generation на частных бизнес-данных, а Supabase объединяет его с аутентификацией и хранилищем, разговор «нам нужна отдельная векторная БД» становится короче с каждым кварталом. Команды, с которыми я работал, уже по умолчанию используют pgvector для всего, что не превышает нескольких сотен миллионов эмбеддингов, и обращаются к выделенным векторным движкам только когда бюджеты по задержке становятся жёсткими. $500 миллионов усиливают эту гравитацию.

Firebase — другая очевидная мишень. Supabase начинал жизнь как open-source альтернатива, и AI-угол играет на его сильные стороны. Сгенерированный код куда охотнее пишет SQL против задокументированной схемы, чем выстраивает цепочки проприетарных NoSQL-запросов. Когда Cursor или Claude Code создаёт scaffold проекта, победят предсказуемые примитивы.

Неудобное прочтение: управляемые Postgres-провайдеры без AI-истории — тихие проигравшие здесь. RDS, Cloud SQL и различные Postgres-as-a-service решения по-прежнему владеют enterprise-нагрузками, но не объединяют аутентификацию, хранилище, realtime, edge compute и pgvector за одним SDK. Их ров — соответствие требованиям и интеграция с остальным облачным аккаунтом, а не любовь разработчиков.

Командам платформ в iGaming и fintech стоит читать это с неоднозначными чувствами. Бандл Supabase отлично подходит для greenfield AI-функций (внутрипродуктовые копайлоты, поиск сигналов мошенничества, персонализированные предложения), но операционная зрелость для регулируемых транзакционных нагрузок в режиме 24/7 по-прежнему уступает скучным игрокам рынка. Ближайшие 90 дней принесут множество проектов «давайте пилотируем Supabase для AI-ассистента». Это правильный масштаб. Но не кладите на него свой кошелёк-леджер пока что.

Для стартапов, создающих AI-native продукты, этот раунд — по большей части хорошая новость. Больше финансирования означает больше инженеров на производительность pgvector, больше регионов для Edge Functions и более громкий enterprise-сейлз, который тащит за собой compliance-сертификации.

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

Если вы руководите платформой и оцениваете всё это — вот что стоит сделать на этой неделе.

Во-первых, проведите аудит того, где хранятся ваши эмбеддинги. Если вы используете отдельную векторную базу данных для менее чем пятидесяти миллионов векторов, а основное хранилище уже Postgres — запустите бенчмарк pgvector против ваших реальных паттернов запросов. Экономия от консолидации в команде из 10 человек легко может составить операционную нагрузку одного инженера.

Во-вторых, зафиксируйте предположения о версии Supabase. Платформа развивается быстро, а раунд в $500 миллионов означает больше поставок — а значит, больше breaking changes ниже по стеку от вас. Зафиксируйте версии клиентских библиотек. Читайте changelogs. Не позволяйте автосгенерированному SDK в вашем AI-инструменте для написания кода дрейфовать схему вашего production.

В-третьих, рассматривайте Multigres v0.1 как сигнал о дорожной карте, а не как продукт. Не планируйте миграцию вокруг альфа-программного обеспечения. Если вы сталкиваетесь с проблемами масштабирования Postgres сегодня, ответом по-прежнему являются read-реплики, партиционирование и connection pooling, а не слой шардирования, который ещё не прошёл через год инцидент-репортов.

В-четвёртых, если вы используете Cursor, Claude Code или любой агент в стиле Codex для генерации backend-кода — напишите внутреннее руководство по стилю для принимаемых паттернов Supabase. Политики Row Level Security, таймауты Edge Function, выбор индекса pgvector. Сгенерированный код с удовольствием пропустит всё три.

В-пятых, договаривайтесь сейчас, если работаете в масштабе. Раунды по оценке смещают ценовую власть. Фиксируйте многолетние условия до того, как enterprise-тариф будет пересмотрен.

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

  • Supabase привлёк $500 миллионов при постденежной оценке $10,5 миллиарда под руководством GIC; Salesforce Ventures вошёл в раунд, Stripe увеличил свою долю.
  • Тезис: AI-инструменты для написания кода (Cursor, Claude Code, агенты в стиле Codex) предпочитают знакомые, хорошо задокументированные backend-примитивы, а Postgres плюс pgvector — путь наименьшего сопротивления.
  • pgvector хранит эмбеддинги рядом с данными приложения, что подрывает аргументы в пользу отдельных векторных баз данных для многих AI-нагрузок.
  • Multigres v0.1 альфа сигнализирует об амбициях enterprise-масштаба, но не является production-инфраструктурой. Относитесь к нему как к дорожной карте, а не к цели миграции.
  • Edge Functions с возможностью AI-инференса позиционируют Supabase как backend приложений, а не просто как базу данных — это правильный фрейминг для следующих двух лет работы над AI-продуктами.

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

В: Является ли Supabase реальной альтернативой Firebase для production AI-приложений?

Для greenfield AI-функций и приложений малого и среднего размера — да. Фундамент на Postgres, поддержка pgvector и встроенные аутентификация и хранилище покрывают большинство AI-нагрузок прикладного уровня. Для высоконагруженных регулируемых транзакционных систем скучные игроки рынка по-прежнему имеют лучший операционный послужной список.

В: Заменяет ли pgvector специализированные векторные базы данных, такие как Pinecone или Weaviate?

Для нагрузок с менее чем несколькими сотнями миллионов эмбеддингов, где данные уже хранятся в Postgres, pgvector обычно выигрывает по операционной простоте. Специализированные векторные движки по-прежнему важны, когда бюджеты задержки запросов жёсткие или количество векторов очень велико.

В: Должны ли инженерные команды внедрять Multigres после объявления Supabase?

Нет. Multigres v0.1 находится в альфа-версии. Проблемы масштабирования production Postgres по-прежнему следует решать с помощью read-реплик, партиционирования, connection pooling и тщательной оптимизации запросов. Следите за Multigres, но не ставьте миграцию на альфа-программное обеспечение.

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