Это перевод свежего обзора индустрии баз данных, написанного в начале 2026 года. Если вы думали, что PostgreSQL уже некуда расти, держитесь крепче: в статье рассказывается, как в 18-й версии «слон» наконец-то избавился от зависимости от страничного кэша ОС благодаря новой подсистеме асинхронного ввода-вывода. Почему это событие стало поворотным моментом года и как Microsoft, Amazon и Google перекроили свои облака под этот стандарт — читайте в материале.

PostgreSQL продолжает доминировать

Впервые я написал о том, как PostgreSQL захватывает мир баз данных, ещё в 2021 году. Этот тренд продолжается и сейчас: самые интересные события в индустрии вновь происходят вокруг PostgreSQL.

В ноябре 2025 года вышла PostgreSQL v18. Её самая заметная фича — новая подсистема асинхронного ввода-вывода (AIO), которая наконец-то избавит PostgreSQL от зависимости от страничного кэша ОС. Сюда же добавили поддержку skip scans — теперь запросы могут использовать составные индексы B-tree даже при отсутствии условий на первые столбцы. А ещё улучшили оптимизатор запросов, например удалили избыточные самосоединения.

Знатоки баз данных могут заметить, что это вовсе не прорывные возможности и в других СУБД они существуют годами. PostgreSQL остаётся единственной крупной СУБД, полагающейся на страничный кэш ОС. А Oracle поддерживала skip scans ещё с 2002 года (v9i)! Почему же я считаю, что главные события мира БД в 2025-м происходили вокруг PostgreSQL?

Дело в том, что основная активность и движение в индустрии сосредоточились вокруг компаний, продуктов, проектов, связанных с PostgreSQL.

Покупки и запуски

В прошлом году самый популярный стартап в области данных (Databricks) заплатил $1 млрд за PostgreSQL-DBaaS-компанию Neon. Затем одна из крупнейших компаний в мире БД Snowflake купила за $250 млн другого провайдера PostgreSQL — CrunchyData. А один из технологических гигантов — Microsoft — запустил свой новый PostgreSQL-DBaaS-сервис HorizonDB.

Архитектурно Neon и HorizonDB следуют концепции Amazon Aurora из 2010-х годов: разделение вычислений и хранения (compute and storage) с одним ведущим узлом. Сейчас PostgreSQL-сервис от Snowflake использует ту же архитектуру, так как они строят решение на базе Crunchy Bridge.

Распределённый PostgreSQL

Все перечисленные выше сервисы используют архитектуру с одним ведущим узлом: приложения отправляют ведущему узлу запросы на запись, а он передаёт эти изменения репликам. Но в прошлом году анонсировали два новых проекта по созданию горизонтально масштабируемых сервисов для PostgreSQL. В июне 2025-го Supabase объявила о найме Сугу (Sugu) — соавтора Vitess и бывшего соучредителя/CTO PlanetScale. Он возглавил проект Multigres, цель которого — создать промежуточное ПО для шардинга PostgreSQL аналогично шардингу MySQL в Vitess. Сугу покинул PlanetScale в 2023 году и был вынужден «залечь на дно» на два года. Теперь, вероятно, урегулировав юридические вопросы, он готов действовать в Supabase. Это действительно значимое событие, когда анонс уделяет больше внимания инженеру, чем самой системе.

Через месяц после новостей о Multigres компания PlanetScale анонсировала собственный проект «Vitess-для-PostgreSQL» под названием Neki. PlanetScale запустила свой первоначальный сервис PostgreSQL в марте 2025 года, но архитектурно он представляет собой стандартный одноузловой PostgreSQL с pgBouncer.

Обновление от 05.01.2026: Мне напомнили про PgDog — это система с открытым исходным кодом, которая реализует горизонтальный шардинг в PostgreSQL. Ранее я относил PgDog к категории пулеров соединений (как PgBouncer), но на самом деле это конкурент Multigres и Neki.

Коммерческий ландшафт

С запуском HorizonDB от Microsoft в 2025 году все крупные облачные провайдеры обзавелись собственными серьёзными PostgreSQL-проектами. Amazon предлагает Aurora PostgreSQL с 2017 года. Google выпустила AlloyDB в 2022-м. ServiceNow в 2024-м запустила сервис RaptorDB, основанный на приобретении Swarm64 в 2021 году. Даже такой динозавр, как IBM, предлагает свою облачную версию PostgreSQL с 2018 года. Oracle выпустила свой сервис PostgreSQL в 2023-м, хотя ходят слухи, что их внутренняя команда PostgreSQL попала под сокращение в рамках увольнений в подразделении MySQL OCI в сентябре 2025 года.

Всё ещё существует несколько независимых (Independent Software Vendor, ISV) компаний, предоставляющих PostgreSQL DBaaS. Supabase, вероятно, крупнейшая из них по количеству инстансов. Среди других — YugabyteDB, TigerData (ранее TimeScale), PlanetScale, Xata, PgEdge и Nile. Изначально Xata строила свою архитектуру на Amazon Aurora, но в этом году объявила о переходе на собственную инфраструктуру. ParadeDB пока не анонсировала свой хостинговый сервис. Tembo закрыла свой хостинг PostgreSQL в 2025 году, переключившись на разработку агента для настройки баз данных. Hydra и PostgresML в этом году обанкротились и выбыли из игры. Другие системы предоставляют совместимый с Postgres интерфейс, но их бэкенд не основан на PostgreSQL (например, CockroachDB, CedarDB, Google Spanner). Существуют и хостинг-компании, такие как Aiven и Tessel, которые предлагают PostgreSQL как сервис (DBaaS) наряду с другими системами.

Мнение Энди

Неясно, кто станет следующим крупным покупателем, после того как Databricks и Snowflake приобрели компании, связанные с PostgreSQL. Повторюсь, у каждого крупного техногиганта уже есть своё предложение Postgres. EnterpriseDB, старейший независимый вендор PostgreSQL, упустил два самых значимых поглощения за последние пять лет. Им остаётся надеяться на Bain Capital или на то, что HPE купит их (хотя этому партнёрству уже восемь лет). Ситуация со слияниями и поглощениями вокруг PostgreSQL напоминает скупку OLAP-систем в конце 2000-х, когда Vertica осталась «последней на остановке» после поглощения AsterData, Greenplum и DATAllegro.

Развитие трёх конкурирующих проектов распределённого PostgreSQL (Multigres, Neki, PgDog) — позитивная новость. Это не первая попытка подобного рода: Greenplum, ParAccel и Citus уже два десятилетия выдерживают OLAP-нагрузки. Citus поддерживает и OLTP, но начиная с 2010 года фокусируется на аналитике. Для поддержки OLTP 15 лет назад проект NTT RiTaDB объединился с GridSQL и создал Postgres-XC, разработчики которого основали StormDB, который в 2013 году приобрела Translattice. Postgres-X2 был попыткой модернизировать XC, но разработчики забросили этот проект. Translattice открыла исходный код StormDB как Postgres-XL, но проект неактивен с 2018 года. YugabyteDB появилась в 2016 году и, вероятно, является самой распространённой системой шардированного PostgreSQL (и остаётся опенсорсной!), но её исходный код безнадёжно застрял на версии PostgreSQL 15. Amazon анонсировала свой шардированный PostgreSQL (Aurora Limitless) в 2024 году, но это закрытое решение.

Microsoft купила Citus в 2019 году, но из-за путаницы с именованием продуктов трудно уследить за тем, что они делали до HorizonDB. В 2019 году Citus переименовали в Azure Database for PostgreSQL Hyperscale, а в 2022-м — в Azure Cosmos DB for PostgreSQL. Ещё есть Azure Database for PostgreSQL with Elastic Clusters, который тоже использует Citus, но это не то же самое, что Azure Cosmos DB for PostgreSQL. Microsoft прекратила поддержку Azure PostgreSQL Single Server в 2023 году, но сохранила Azure PostgreSQL Flexible Server. Столько Azure, что в глазах рябит! По крайней мере, Microsoft хватило ума назвать новую систему просто Azure HorizonDB.

Команда PlanetScale не испытывает тёплых чувств к конкурентам и известна своими нападками на Neon и Timescale. Конфликты между компаниями — дело не новое (вспомните Yugabyte против CockroachDB или Databricks против Snowflake). Подозреваю, что в будущем мы увидим больше подобных столкновений, по мере того как «войны PostgreSQL» будут разгораться. Я бы посоветовал этим небольшим компаниям критиковать крупных облачных провайдеров, а друг друга всуе не упоминать.

MCP для каждой базы данных!

Если в 2023-м каждая СУБД добавляла векторный индекс, то в 2025-м все добавили поддержку Model Context Protocol (MCP) от Anthropic.

MCP — это стандартизированный клиент-серверный интерфейс JSON-RPC, который позволяет языковым моделям взаимодействовать с внешними инструментами и источниками данных без необходимости написания связующего кода. Сервер MCP выступает в роли промежуточного звена перед СУБД и публикует список инструментов, данных и действий, которые предоставляет. Клиент MCP (например, хост LLM, такой как Claude или ChatGPT) обнаруживает и использует эти инструменты. В случае с базами данных сервер MCP преобразует эти запросы в соответствующие запросы к БД (например, SQL) или управляющие команды. Иными словами, MCP — это посредник, который следит за порядком, чтобы база данных и LLM достаточно доверяли друг другу.

Anthropic анонсировала MCP в ноябре 2024 года, но настоящий взлёт произошёл в марте 2025-го, когда OpenAI объявила о поддержке MCP в своей экосистеме. В течение следующих нескольких месяцев каждый вендор СУБД выпустил MCP-серверы для всех категорий систем: OLAP (ClickHouse, Snowflake, Firebolt, Yellowbrick), SQL (YugabyteDB, Oracle, PlanetScale) и NoSQL (MongoDB, Neo4j, Redis). Поскольку официального MCP-сервера для Postgres не существует, каждый провайдер Postgres DBaaS выпустил собственный (Timescale, Supabase, Xata). Облачные провайдеры выпустили мультисистемные MCP-серверы, способные взаимодействовать с любыми их управляемыми сервисами баз данных (Amazon, Microsoft, Google). Единый шлюз для общения с разнородными базами данных — это почти, но не совсем святой Грааль федеративных баз данных. Насколько мне известно, любой запрос в этих серверах MCP работает только с одной базой данных, поэтому приложение само отвечает за соединение данных между источниками.

Помимо официальных реализаций серверов MCP от вендоров, существуют сотни сторонних реализаций. Некоторые из них пытаются поддерживать несколько систем (например, DBHub, DB MCP Server). DBHub опубликовал хороший обзор серверов MCP для PostgreSQL.

Интересной функцией, оказавшейся полезной для агентов, стало вет��ление баз данных (database branching). Хотя эта технология не специфична для серверов MCP, ветвление позволяет агентам быстро тестировать изменения в базе данных, не затрагивая производственные приложения. Neon сообщила в июле 2025 года, что агенты создают 80% их баз данных. Neon изначально проектировался с поддержкой ветвления, тогда как другие системы добавили эту поддержку позже.

Мнение Энди

С одной стороны, я рад, что теперь существует стандарт для предоставления доступа к базам данных большему числу приложений. Но никто не должен доверять приложению неограниченный доступ к БД, неважно — через MCP или обычный API. Хорошей практикой остаётся предоставление учётным записям минимально необходимых привилегий. Ограничение прав особенно важно для неконтролируемых агентов, которые могут начать вести себя непредсказуемо внутри вашей базы данных. Это означает, что ленивые практики, такие как выдача прав администратора каждой учётной записи или использование одной учётной записи для всех сервисов, приведут к катастрофе, когда LLM выйдет из-под контроля. Конечно, если ваша компания оставляет базу данных открытой для всего мира, пока вы обрушиваете акции одной из богатейших компаний на $600 млрд, то мошеннические запросы MCP не главная ваша забота.

Мой поверхностный анализ нескольких реализаций серверов MCP говорит, что это простые прокси, которые транслируют запросы JSON MCP в запросы к базе данных. Там нет глубокой интроспекции для понимания цели запроса и его уместности. Кто-то обязательно попытается заказать 18 000 стаканчиков для воды через ваше приложение, и вам нужно сделать так, чтобы это не обрушило базу данных. Некоторые серверы MCP имеют базовые механизмы защиты (например, ClickHouse разрешает только чтение), но этого недостаточно. DBHub добавляет несколько уровней защиты, например ограничивает число записей в ответе на один запрос и вводит тайм-ауты выполнения запросов. В документации Supabase тоже есть рекомендации для MCP-агентов, но они, увы, рассчитаны на то, что люди будут им следовать. А как известно, если полагаться на людей, которые должны всё сделать правильно, рано или поздно что-нибудь обязательно пойдёт не так.

Корпоративные СУБД уже давно оснащены автоматическими «ограждениями» и другими механизмами безопасности, которых у опенсорсных решений, как правило, нет. Поэтому они заметно лучше подготовились к агентному будущему. Например, IBM Guardium и Oracle Database Firewall умеют выявлять и блокировать аномальные запросы. Я не пытаюсь рекламировать бигтех, но примеров того, как агенты будут портить людям жизнь, — скажем, случайно удаляя базы данных, — мы ещё увидим немало. Связка MCP-серверов с прокси (например, пуллингом соединений) — отличная точка для внедрения автоматических защитных механизмов.

Противостояние MongoDB и FerretDB

MongoDB уже два десятилетия остаётся одним из столпов в мире NoSQL. В 2021 году Percona запустила FerretDB, задумав его как промежуточный прокси, который переводит MongoDB-запросы в SQL и отправляет их в PostgreSQL. Такой прокси позволяет приложениям под MongoDB переехать на PostgreSQL без переписывания запросов.

Несколько лет проекты мирно сосуществовали, но в 2023 году MongoDB направила FerretDB письмо с требованием прекратить деятельность. Компания заявила, что FerretDB нарушает её патенты, авторские права и товарные знаки, а также условия лицензии на документацию и спецификацию клиент-серверного протокола MongoDB. В мае 2025 года история вышла в публичную плоскость: MongoDB пошла ва-банк и подала федеральный иск. В числе претензий то, что FerretDB называет себя прямой заменой для MongoDB без какого-либо разрешения. В судебных документах фигурирует стандартный набор обвинений: введение разработчиков в заблуждение, размывание бренда и ущерб репутации.

Ситуацию дополнительно запутало объявление Microsoft о передаче в Linux Foundation своего MongoDB-совместимого DocumentDB. На сайте проекта прямо сказано, что DocumentDB совместим с драйверами MongoDB и нацелен на создание «опенсорсной документальной базы данных, совместимой с MongoDB». В проекте участвуют и другие крупные игроки, например Amazon и Yugabyte. На первый взгляд, формулировки выглядят подозрительно похожими на то, в чём MongoDB как раз обвиняет FerretDB.

Мнение Энди

Мне не удалось найти примеры, когда одна компания — разработчик СУБД судилась с другой именно из-за воспроизведения её API. Самый близкий кейс — это иск Oracle к Google по поводу полного воспроизведения Java API в Android. В итоге Верховный суд США встал на сторону Google, признав такое использование добросовестным, и это решение заметно повлияло на юридическое отношение к повторной реализации API.

Чем закончится иск, если он вообще дойдёт до суда, я предсказать не берусь. Присяжные, случайно набранные с улицы, вряд ли разберутся в тонкостях протокола MongoDB, но вот то, что FerretDB изначально назывался MangoDB, они поймут без всяких пояснений. Убедить присяжных, что смена одной буквы в названии не была попыткой увести клиентов, будет непросто. Тем более что само имя вовсе не оригинальное: уже существует пародийная СУБД MangoDB, которая в шутку пишет все данные прямо в /dev/null.

И раз уж мы заговорили о названиях систем баз данных, выбор Microsoft имени DocumentDB неудачен. Уже существуют Amazon DocumentDB (который, кстати, также совместим с MongoDB), InterSystems DocDB, и Yugabyte DocDB. Изначальное название Microsoft для Cosmos DB также было DocumentDB ещё в 2016 году.

Наконец, в судебном иске MongoDB утверждается, что они «были пионерами в разработке „нереляционных“ баз данных». Это утверждение неверно. Первые универсальные СУБД были нереляционными, потому что реляционную модель ещё не изобрели. Integrated Data Store от General Electric (1964) использовала сетевую модель данных, а Information Management System от IBM (1966) — иерархическую. MongoDB также не является первой документальной СУБД. Этот титул принадлежит объектно-ориентированным СУБД конца 1980-х (например, Versant) или XML-СУБД 2000-х (например, MarkLogic). MongoDB — наиболее успешная из этих концепций с огромным отрывом (кроме, возможно, IMS).

Поле битвы файловых форматов

Форматы файлов — это область систем данных, которая оставалась практически без изменений последнее десятилетие. В 2011 году Meta выпустила колоночный формат для Hadoop под названием RCFile. Два года спустя Meta доработала RCFile и анонсировала формат ORC (Optimized Record Columnar File), основанный на PAX. Через месяц после релиза ORC Twitter и Cloudera выпустили первую версию Parquet. Спустя почти 15 лет Parquet доминирует среди опенсорсных форматов.

В 2025 году вышли пять новых опенсорсных форматов, претендующих на то, чтобы свергнуть Parquet с пьедестала:

К выпущенным в 2024 году форматам присоединились новые:

SpiralDB произвела самый большой фурор в этом году, объявив о передаче Vortex в Linux Foundation и создании управляющего комитета из нескольких организаций. Microsoft тихо закрыла проект Amudai (или, по крайней мере, его исходный код) в конце 2025 года. Другие проекты (FastLanes, F3, AnyBlox) — это академические прототипы. AnyBlox получила награду за лучшую статью на VLDB в этом году.

Эта конкуренция подстегнула сообщество разработчиков Parquet к модернизации его возможностей. См. подробный технический анализ файловых форматов с колоночным хранением от главы Parquet PMC (Julien Le Dem).

Мнение Энди

Главная проблема Parquet — вовсе не в самом формате. Спецификация может эволюционировать, и она действительно это делает. Никто не ожидал, что компании будут переписывать петабайты легаси-файлов только ради обновления до последней версии Parquet. Проблема в другом: существует огромное количество реализаций библиотек чтения и записи на разных языках, и все они поддерживают разные подмножества спецификации. Наш анализ Parquet-файлов «в дикой природе» показал, что 94% из них используют исключительно возможности v1 образца 2013 года, при том что файлы созданы после 2020-го. Этот «наименьший общий знаменатель» приводит к тому, что если кто-то создаёт Parquet-файл с использованием возможностей v2, далеко не факт, что конкретная система вообще сможет его прочитать.

Я работал над файловым форматом F3 вместе с коллегами из Университета Цинхуа (Синьюй Цзэн, Жуйцзюнь Мэн, Хуаньчэнь Чжан), Университета Карнеги — Меллона (Мартин Праммер, Джигнеш Патель) и Уэсом Маккинни. Мы сосредоточились на решении проблемы совместимости: формат предоставляет как нативные декодеры в виде разделяемых библиотек (crates на Rust), так и встроенные WASM-версии этих декодеров прямо внутри файла. Если вводится новая кодировка, а в СУБД нет для неё нативной реализации, система всё равно сможет прочитать данные через WASM-декодер, передавая их в виде Arrow-буферов. Каждый декодер работает с одной колонкой, поэтому СУБД может комбинировать нативные и WASM-декодеры даже в рамках одного файла. AnyBlox идёт другим путём, генерируя одну WASM-программу для декодирования всего файла целиком.

Кто в итоге выиграет войну форматов, я не берусь предсказывать. Следующее поле боя, скорее всего, поддержка GPU. SpiralDB, похоже, движется в правильном направлении, но всепроникающее распространение Parquet будет очень непросто перебить. И это я ещё даже не затрагивал попытки DuckLake перевернуть экосистему Iceberg…

Разумеется, как только заходит разговор о стандартах, кто-нибудь обязательно постит тот самый комикс xkcd про конкурирующие форматы. Я его уже видел. Можете не присылать.

Случайные события

Базы данных — это большие деньги. Давайте пройдёмся по сделкам!

Покупки

На рынке было много движухи. Pinecone сменила CEO в сентябре, готовясь к поглощению, но дальше слухов дело, похоже, не пошло. А вот сделки, которые действительно состоялись:

  • DataStax → IBM
    Один из столпов экосистемы Cassandra был куплен IBM в начале года примерно за 3 млрд долларов.

  • Quickwit → DataDog
    Компанию, стоящую за заменой Lucene, движка полнотекстового поиска Tantivy, купили в начале года. Хорошая новость: разработка Tantivy продолжается.

  • SDF → dbt
    Отличное приобретение для dbt в рамках их анонса Fusion в этом году. SDF позволяе�� делать более строгий SQL-анализ внутри DAG.

  • Voyage.ai → MongoDB
    Mongo приобрела AI-стартап на ранней стадии, чтобы расширить RAG-возможности в своём облаке. Один из моих лучших студентов устроился в Voyage за неделю до анонса сделки. Он думал, что «предаёт семью», не пойдя в компанию по базам данных, и в итоге всё равно оказался в одной из них.

  • Neon → Databricks
    Судя по всему, за эту PostgreSQL-компанию шла настоящая война ставок, но Databricks выложила аппетитный миллиард долларов. Neon до сих пор существует как отдельный сервис, но Databricks быстро переименовал его внутри своей экосистемы в Lakebase.

  • CrunchyData → Snowflake
    Snowflake просто не могла позволить, чтобы летом всё внимание досталось Databricks, поэтому заплатила 250 млн долларов за 13-летнюю PostgreSQL-компанию CrunchyData. В последние годы Crunchy активно нанимала бывших ключевых разработчиков Citus и развивала своё DBaaS-предложение, пока Snowflake не выписала чек. В декабре 2025 Snowflake объявила публичный превью своего Postgres-сервиса.

  • Informatica → Salesforce
    ETL-ветеран из 1990-х, Informatica, был куплен Salesforce за 8 млрд долларов. До этого компания вышла на биржу в 1999-м, ушла с неё в 2015-м и снова стала публичной в 2021 году.

  • Couchbase ушла с биржи
    Честно говоря, я так и не понял, как Couchbase смогла выйти на IPO в 2021 году. Видимо, ехали на хвосте успеха MongoDB. Несколько лет назад Couchbase делала интересные вещи, заимствуя компоненты из проекта AsterixDB (UC Irvine).

  • Tecton → Databricks
    Tecton даёт Databricks дополнительные инструменты для построения агентов. Ещё один мой бывший студент работал в Tecton и теперь тоже трудиться в Databricks.

  • Tobiko Data → Fivetran
    Эта команда стоит за двумя полезными инструментами: SQLMesh и SQLglot. Первый — единственный вменяемый опенсорсный конкурент dbt (см. ниже про их грядущее объединение с Fivetran). SQLglot — удобный SQL-парсер/депарсер с эвристическим оптимизатором запросов. В связке с Fivetran и SDF у dbt получается интересная технологическая комбинация на ближайшие годы.

  • SingleStore ушла с биржи
    PE-фонд Vector Capital, купивший SingleStore, уже имеет опыт управления СУБД-компаниями. В 2020 году они купили XML-базу MarkLogic и перепродали её Progress в 2023.

  • Codership → MariaDB
    После покупки MariaDB Corporation фондом PE в 2024 году компания активно занялась поглощениями. Первая покупка — компания, стоящая за Galera Cluster, решением для масштабирования MariaDB. См. мой обзор «катастрофы с MariaDB» за 2023-м год.

  • SkySQL → MariaDB
    Вторая покупка MariaDB — и тут начинается цирк. Изначально коммерческая компания называлась SkySQL Corporation (2010), затем в 2014-м переименовалась в MariaDB Corporation. В 2020 году MariaDB Corporation выпустила DBaaS под названием SkySQL. Из-за финансовых проблем в 2023-м SkySQL выделили в отдельную компанию. И вот в 2025 году MariaDB Corporation замкнула круг, выкупив SkySQL обратно. Такого хода в своём «бинго по базам данных» я в этом году не ожидал.

  • Crystal DBA → Temporal
    Компания, разрабатывающая инструмент автоматической оптимизации баз данных, ушла в Temporal, чтобы автоматически оптимизировать базы данных! Рад слышать, что основатель Crystal и выпускник Berkeley DB Group Йоханн Шляйер-Смит успешно там работает.

  • HeavyDB → Nvidia
    Эта система (бывшая OmniSci, ещё раньше MapD) была одной из первых GPU-ускоренных СУБД, запущена в 2013 году. Я не нашёл официального анонса сделки — только упоминание у фирмы, которая ею занималась. А потом у нас была встреча с Nvidia по поводу исследований в области баз данных, и там внезапно появились знакомые из HeavyDB.

  • DGraph → Istari Digital
    Dgraph была куплена Hypermode в 2023. Похоже, Istari купила именно Dgraph, а не всю Hypermode (или просто отказалась от остального). Я до сих пор не встречал людей, которые активно используют Dgraph.

  • DataChat → Mews
    Один из первых проектов «чат с вашей базой данных», вышедший из Университета Висконсина и от нынешнего профессора группы баз данных в Университете Карнеги — Меллона Джигнеша Пателя. В итоге был куплен европейским SaaS-поставщиком для управления отелями. Делайте из этого какие хотите выво��ы.

  • Datometry → Snowflake
    Datometry уже несколько лет работает над опасной задачей автоматического перевода устаревших SQL-диалектов (например, Teradata) в современные OLAP-системы. Snowflake купила их для расширения инструментов миграции. Дополнительная инфа в Datometry 2020 CMU-DB tech talk.

  • LibreChat → ClickHouse
    Как и покупка Datometry у Snowflake, это хороший пример улучшения взаимодействия разработчиков с высокопроизводительными OLAP-движками.

  • Mooncake → Databricks
    После покупки Neon Databricks приобрела Mooncake, чтобы PostgreSQL могла читать и писать данные в Apache Iceberg. Подробнее — в докладе Neon Databricks о Mooncake.

  • Confluent → IBM
    Классический пример того, как вырастить компанию из опенсорсного проекта. Kafka была разработана в LinkedIn в 2011 году, Confluent выделилась в стартап в 2014 году, вышла на IPO в 2021-м, а затем IBM выписала крупный чек. Как и в случае с DataStax, остаётся вопрос: поступит ли IBM с Confluent так же, как обычно поступает с поглощёнными компаниями, или позволит ей остаться автономной, как Red Hat.

  • Gel → Vercel
    Ранее известная как EdgeDB, эта компания разрабатывала DSL поверх PostgreSQL и была куплена Vercel в конце года.

  • Kuzu → ?
    Встраиваемая графовая СУБД из Университета Ватерлоо была куплена неназванной компанией в 2025 году. После этого компания KuzuDB объявила о прекращении опенсорсной разработки. Проект LadybugDB — попытка поддерживать форк кода Kuzu.

Слияния

Неожиданная новость прилетела в октябре 2025 года: Fivetran и dbt Labs объявили о слиянии.

Последнее крупное слияние в мире баз данных, которое приходит мне в голову, — это объединение Cloudera и Hortonworks в 2019 году. Но та сделка получилась неуклюжей: две компании в отчаянных попытках отыскать рыночную значимость с Hadoop слились в одну, но это не помогло. Формально сюда же можно отнести и слияние MariaDB Corporation с Angel Pond Holdings Corporation в 2022 году через SPAC, но, по сути, это был обходной путь к IPO. И для инвесторов он закончился печально.

Слияние Fivetran + dbt — история совсем другого уровня (и куда более позитивная): две технологически дополняющие друг друга компании объединились, чтобы стать ETL-гигантом и подготовиться к полноценному IPO в обозримом будущем.

Инвестиции

Если я ничего не пропустил среди публично анонсированных сделок, то раундов раннего финансирования у стартапов в области баз данных в этом году было немного. Хайп вокруг векторных СУБД поутих, и венчурные фонды сейчас выписывают чеки почти исключительно компаниям из мира LLM.

Переименования

Новая категория в моём ежегодном обзоре — компании из мира баз данных, решившие сменить название предприятия или продукта.

  • HarperDB → Harper
    Компания, разрабатывающая JSON-ориентированную СУБД, убрала «DB», чтобы подчеркнуть позиционирование себя как платформы для приложений с БД — в духе Convex или Heroku. Мне симпатичны ребята из Harper. В своём техническом докладе на семинаре группы баз данных Университета Карнеги — Меллона в 2021 году они представили, пожалуй, худшую идею СУБД, которую я когда-либо слышал. К счастью, осознав, насколько это было плохо, они от неё отказались и перешли на LMDB.

  • EdgeDB → Gel
    Слово Edge создаёт ощущение, что речь идёт о базе данных для edge-устройств или сервисов (например, Fly.io). А вот передаёт ли название Gel более высокоуровневые цели проекта — большой вопрос. Смотрите доклад о языке запросов Gel (который всё ещё называют EdgeQL) выпускника PhD программы CMU.

  • Timescale → TigerData
    Редкий случай переименования компании, чтобы дистанцироваться от своего основного продукта. Обычно всё происходит наоборот: компании берут имя своей СУБД (Relational Software, Inc. → Oracle Systems Corporation; 10gen, Inc. → MongoDB, Inc.). Но в этом случае логика понятна: компании важно избавиться от образа нишевой СУБД для временных рядов и закрепиться как улучшенная версия PostgreSQL для задач общего назначения, поскольку рынок PostgreSQL как универсальной платформы гораздо шире.

Закрывшиеся проекты

Признаюсь честно, я был техническим советником двух из этих закрывшихся стартапов. Мой послужной список как советника сейчас выглядит ужасно. Я был советником Splice Machine, но они закрылись в 2021 году. В своё оправдание скажу, что я обсуждаю с этими компаниями только технические идеи, а не бизнес-стратегии. И я говорил Fauna, что им следует добавить поддержку SQL, но они не прислушались к моему совету.

  • Fauna
    Интересная распределённая СУБД, основанная на исследованиях Дэна Абади в области детерминированного управления параллелизмом. Они предложили строго согласованные транзакции именно тогда, когда угасал интерес к NoSQL, а Spanner снова сделал транзакции популярными. Но они сделали ставку на проприетарный язык запросов и GraphQL.

  • PostgresML
    Идея казалась очевидной: позволить людям запускать операции ML/AI внутри их СУБД PostgreSQL. Проблема заключалась в том, чтобы убедить людей перевести существующие базы данных на их хостинговую платформу. Один из соучредителей перешёл в Anthropic, другой создал новый прокси-проект под названием pgDog.

  • Derby
    Одна из первых СУБД на Java, берущая начало в 1997 году (изначально называлась Java DB, или JBMS). IBM передала её Apache Foundation в 2000-х, а там переименовали в Derby. В октябре 2025 года проект объявил о переходе в режим «только для чтения», так как никто больше его не поддерживает.

  • Hydra
    Хотя официального объявления не было, соучредители и сотрудники стартапа «DuckDB внутри Postgres» разбрелись по другим компаниям.

  • MyScaleDB
    Это был форк ClickHouse, добавляющий векторный поиск и полнотекстовое индексирование с использованием Tantivy. Они объявили о закрытии в мае 2025 года.

  • Voltron Data
    Предполагалось, что это будет «супергруппа» компаний по базам данных. Представьте себе команду тяжеловесов вроде Run the Jewels. Там были топовые инженеры из Nvidia Rapids, создатель Apache Arrow и Python Pandas, а также гении GPU из BlazingSQL. Добавьте к этому $110 млн венчурных денег от ведущих компаний, включая будущего генерального директора Intel (и члена совета попечителей CMU). Они строили базу данных с ускорением на GPU (Theseus), но не смогли запустить её вовремя.

Наконец, хотя это и не бизнес, было бы неправильно не упомянуть закрытие IBM Research Almaden. IBM построила этот центр в 1986 году, и десятилетиями он был Меккой исследований баз данных. Я проходил собеседование в Almaden в 2013 году, там было очень красиво. Группа баз данных IBM Research уже не та, что раньше. Тем не менее список выпускников этой священной земли впечатляет: Ракеш Агравал, Дональд Чемберлин, Рональд Фейгин, Лора Хаас, Мохан, Пэт Селинджер, Моше Варди, Дженнифер Уидом и Гай Ломан.

Мнение Энди

Некто заявил, что я якобы оцениваю качество СУБД по объёму денег, которые компания смогла привлечь на её разработку. Это, конечно, неправда. Я слежу за всеми этими событиями по другой причине: рынок исследований в области баз данных сегодня переполнен и невероятно динамичен. Я «соревнуюсь» не только с академиками из других университетов, но и с крупными технологическими корпорациями и небольшими стартапами, которые постоянно выкатывают интересные системы, за которыми нужно следить. Корпоративные исследовательские лаборатории уже не те, что раньше, за исключением Microsoft Research, где до сих пор активно нанимают лучших специалистов и делают по-настоящему выдающуюся работу.

В 2022 году я предсказал, что в 2025-м мы увидим массовые закрытия компаний в области баз данных. Да, закрытий в этом году действительно было больше, чем раньше, но совсем не в тех масштабах, которых я ожидал.

Гибель Voltron и что-то вроде acquihire-сделки вокруг HeavyDB лишь подтверждают тренд: GPU-ускоренные СУБД по-прежнему плохо приживаются. Kinetica уже много лет живёт за счёт госконтрактов, а Sqream вроде бы ещё держится. Но всё это остаётся нишей, и никому так и не удалось всерьёз пошатнуть доминирование СУБД на CPU. Я не знаю кто и как, но в 2026 году вы точно услышите громкие анонсы GPU-ускоренных баз данных от крупных вендоров. Всё это также усиливает ощущение, что OLAP-движки перестают быть чем-то особенным: современные системы стали настолько быстрыми, что разница в производительности базовых операций (сканирования, соединения) минимальна. Поэтому системы отличаются друг от друга по большей части удобством работы и качеством планов запросов, которые строят оптимизаторы.

Поглощения Couchbase и SingleStore PE-фондами могут указывать на новый тренд в индустрии баз данных. Конечно, PE-сделки бывали и раньше, но почти все — в последние годы: MarkLogic в 2020-м, Cloudera в 2021-м и MariaDB в 2023-м. До 2020-го я нашёл лишь два примера: SolidDB в 2007-м и Informatica в 2015-м. Возможно, PE-фонды придут на смену холдингам, которые покупают «уставшие» СУБД и берут плату за поддержку до скончания времён (Actian, Rocket). Да что там говорить: Oracle до сих пор зарабатывает на RDB/VMS, купленной 30 лет назад!

И напоследок — респект Никите Шамгунову. Насколько мне известно, он единственный человек, который стал сооснователем двух компаний в области баз данных (SingleStore и Neon), которые были проданы в течение одного года. Думаю, побить рекорд Никиты в ближайшее время никому не удастся, как и выпуск DMX (RIP) двух альбомов в один год (It's Dark and Hell Is Hot, Flesh of My Flesh), занявших первую строчку рейтинга.

Пик мужской формы

Если и был по-настоящему звёздный год, то это год ветерана БД Ларри Эллисона, которому стукнуло 81. Всего за год он умудрился сделать больше, чем многие за всю жизнь. Расскажу по порядку.

Ларри начал год на третьем месте в списке самых богатых людей мира. Мысль о том, что он стоит меньше, чем Марк Цукерберг, явно не давала ему спать по ночам. Ходили слухи, что бессонница связана с изменением питания после покупки знаменитого британского паба и повышенного потребления пирогов. Но уверяю вас, его «аквавеганская» диета не менялась уже 30 лет. В апреле 2025 года пришла новость: Ларри стал вторым самым богатым человеком в мире. Спать он стал чуть лучше, но всё равно не идеально. Стресса в жизни хватало: например, он наконец решился продать свой редчайший McLaren F1, допущенный к дорогам общего пользования, с оригинальным руководством по эксплуатации в бардачке.

В июле 2025 года Ларри порадовал нас своим третьим твитом за 13 лет (в узких кругах он известен как «#3»). Это было сообщение про Технологический институт Эллисона (EIT), который он основал неподалёку от Оксфорда. Название и ассоциации наводят на мысль о чисто исследовательской некоммерческой организации — чем-то вроде SRI при Стэнфорде или SEI при Университете Карнеги — Меллона. Но на деле это «зонтик» для набора коммерческих предприятий, принадлежащих компании из Калифорнии.

Главная новость года (а может, и века) прогремела в среду, 10 сентября, примерно в 15:00 по восточному времени. После десятилетий ожидания Ларри Джозеф Эллисон наконец стал самым богатым человеком на планете. Акции $ORCL подскочили на 40%, и поскольку Ларри по-прежнему владеет 40% компании, его состояние оценивается в $393 млрд. Для масштаба: это не просто самый богатый человек современности, а самый богатый человек за всю историю человечества. С поправкой на инфляцию пиковые состояния Рокфеллера и Карнеги (да, того самого «C» из CMU) составляли «всего» $340 и $310 млрд.

И это ещё не всё. Oracle участвовала в сделке вокруг американской компании, контролирующей TikTok, а сам Ларри финансировал заявку Paramount (которую контролирует его сын от четвёртого брака) на покупку Warner Bros. Президент США даже в шутку предложил Ларри взять под контроль новостное подразделение CNN, всё-таки он крупнейший акционер Paramount.

Мнение Энди

Даже не знаю, с чего начать. Когда я узнал, что Ларри Эллисон стал самым богатым человеком в мире — и всё это благодаря базам данных, — на душе стало теплее: наконец-то в нашей жизни произошло что-то хорошее. Мне всё равно, что рост акций Oracle был частично «накачан» громкими сделками вокруг ИИ-дата-центров, а не классического софта. Мне всё равно, что потом он лично «потерял» $130 млрд за два месяца. Это как если бы мы с вами спустили зарплату на FortuneCoins: неприятно, придётся две недели есть рис с фасолью, приправляя просроченными пакетиками соуса из бургерной, но выживем.

Некоторые утверждают, что Ларри оторвался от реальности. Или что он сбился с пути, занимаясь вещами, далёкими от баз данных. В пример приводят его гавайскую роботизированную ферму, где салат продаётся по €41 за 1 кг. Или намекают, что у 81-летних мужчин не бывает натуральных светлых волос.

Правда же в том, что Ларри Эллисон покорил мир корпоративных СУБД, спортивного парусного спорта и SPA-курортов для технарей. Логичный следующий шаг — захватить кабельный телеканал, который круглосуточно смотрят тысячи людей в аэропортах. Каждый раз, когда я общаюсь с Ларри, он даёт понять: ему абсолютно всё равно, что о нём говорят. Он знает, что фанаты его любят. Его новая жена его любит. А в итоге это всё, что имеет значение.

Заключение

Прежде чем закончить, хочу передать несколько приветов. Во-первых, PT — за то, что держат Turso под жёстким контролем. Соболезнования JT — по поводу потери работы из-за того, что попались на интрижке с базой данных KevoDB. И обязательно используйте в базах данных для тестирования только фейковые д��нные, а не продавайте их за $175 млн, чтобы в итоге не схлопотать семилетний срок.

Ну и напоследок: у меня и моих PhD-аспирантов появился новый стартап. Надеюсь, скоро смогу рассказать о нём подробнее.