Каким будет энтерпрайз-СУБД в эпоху ИИ

Мы долго жили в парадигме «каждой задаче — свой инструмент»: для документов — Mongo, для аналитики — ClickHouse или Greenplum, для транзакций — старый добрый Postgres. Но опыт последних лет, особенно жесткий краш-тест российской отрасли, показывает: эта концепция трещит по швам. Рынок, наигравшись в специализацию, совершает диалектический виток и возвращается к идее суперуниверсальной СУБД.

Миф о «достаточной ваниле»

В глобальном масштабе рынок СУБД консервативен: Oracle и Microsoft продолжают держать львиную долю энтерпрайза. Россия же стала уникальным полигоном, где этот консерватизм был насильственно сломан.

Главный инсайт этого слома: Open Source в чистом виде не тянет реальный энтерпрайз. Когда бизнес, привыкший к «комфорту» Oracle (RAC, пакеты, продвинутая безопасность, адвайзеры), столкнулся с ванильным Postgres, случился культурный шок.

Мы знали, что Postgres — хорошая, любимая разработчиками СУБД среднего уровня. Но когда ушли западные вендоры, оказалось, что «ваниле» критически не хватает энтерпрайзных фич: надежности, управляемости, безопасности того уровня, к которому привык крупный бизнес. Сегодня наш код в Postgres Pro Enterprise по объему уже сопоставим с кодом самой ванильной версии. Мы написали еще столько же, просто чтобы дотянуть до реальных требований предприятий.

Это вызывает неудобный вопрос к сообществу: а не является ли популярная идея «возьмем бесплатный Postgres и будем счастливы» самообманом для крупных систем? Видимо, да. Рынок неизбежно делится на тех, кто просто «переклеивает шильдики», и тех, кто вынужден инвестировать тысячи человеко-часов в допиливание ядра до уровня коммерческих гигантов прошлого.

Смерть специализированных СУБД

Еще недавно казалось, что будущее за нишевыми продуктами. Однако реальные бизнес-задачи все чаще требуют работы с гетерогенными данными в рамках одного запроса.

Представьте задачу МЧС: прогнозирование ущерба от наводнения. В одном запросе нужно соединить геоинформацию (извилистую линию реки и зону затопления), реляционные данные (список домов, этажность, данные о жильцах-инвалидах) и неструктурированный контент (поэтажные планы в виде картинок, JSON-описания).

Городить огород из пяти разных специализированных баз, а потом пытаться их интегрировать и поддерживать консистенцию данных — это сумасшедший дом. Мы приходим к тому, что Oracle понял давно: СУБД должна быть универсальной. Она должна «переваривать» и JSON, и геоданные, и векторы, и классическую реляционку внутри одной СУБД.

Будущее — за конвергентными СУБД. Выживут не те, кто делает что-то одно идеально, а те, кто делает все достаточно хорошо.

HTAP: святой Грааль аналитики и транзакций

Разделение на OLTP (быстрые короткие транзакции) и OLAP (тяжелую аналитику) долго считалось незыблемым. Но бизнес хочет аналитику в реальном времени, без суточных задержек на переливание данных в DWH. Это породило спрос на гибридную транзакционно-аналитическую обработку (HTAP).

Ванильный Postgres и его форки всегда были заточены под OLTP. Сейчас мы встроили возможность работать с аналитической нагрузкой прямо в Postgres Pro Enterprise.

Как это работает? Через умное совмещение подходов к хранению данных. Для OLTP-запросов используется классическое построчное хранение, а для аналитики — колоночное, которое на порядки эффективнее при агрегации данных по нескольким столбцам. Но самое интересное — это интеграция концепции Lakehouse прямо в ядро СУБД.

Мы можем часть данных хранить в обычных таблицах, а часть — в виде паркетных файлов (Parquet). Эти файлы за счет своей структуры —: поколоночное хранение, сжатие, метаданные с min/max значениями для пропуска ненужных групп строк (row group) и использование SIMD-команд процессора — обеспечивают фантастическую скорость. Запрос, который на обычной реляционной базе работает X секунд, здесь может работать в 20, 30, в 50 раз быстрее. Мы видим, как у заказчиков отчеты начинают строиться мгновенно.

Это меняет не просто скорость, а сам пользовательский опыт. Аналитик, который раньше ждал минуту, пока система построит список уникальных значений для фильтра, теперь получает его моментально. Это и есть настоящий HTAP в действии: транзакционная и аналитическая системы перестают быть двумя разными мирами.

ИИ в СУБД: автономный помощник или идеальный шпион

Искусственный интеллект в базах данных — это не просто модный ChatGPT, который пишет за вас SELECT. Это путь к автономной СУБД, которая сама себя настраивает, защищает и оптимизирует. И это не фантастика, а реальность, которую Oracle начал внедрять несколько лет назад в своей Autonomous Database.

Это не просто база. Это облако, работающее на специализированном железе Exadata, с множеством встроенных механизмов самоуправления. А «за кулисами» работает ПО на основе ИИ, которое анализирует нагрузку, автоматически настраивает параметры и обеспечивает безопасность.

ИИ проникает во все аспекты работы с данными, автоматизируя рутину для:

• администраторов (DBA): огромный пласт рутинных задач по мониторингу, поиску узких мест и настройке можно переложить на ИИ.
• разработчиков: инструменты вроде Cursor AI уже сегодня способны писать код, находить неочевидные ошибки, оптимизировать запросы и даже переводить код с диалекта одной СУБД на другую.
• техподдержки: ИИ может анализировать логи, находить аналогичные инциденты в базе знаний и предлагать решения, ускоряя разрешение проблем.

Однако у этой революции есть две темные стороны.

1. Парадокс безопасности. Чтобы ИИ-помощник был эффективен, ему нужно «скормить» метаданные, а часто и сами данные.

Для меня это было неожиданной проблемой: чтобы ИИ-помощник реально помог с приложением, он должен залезть в структуру базы и посмотреть данные. В этот момент вся наша выстроенная безопасность летит к чертям. Мы получаем новую проблему на ровном месте: как дать ИИ достаточно прав для пользы, но не сделать его идеальным шпионом?

2. Кризис доверия. Главная проблема ИИ сегодня —: ему нельзя слепо верить. Он склонен к «галлюцинациям».

Мы привыкли, что компьютер не врет. Но с ИИ это не так. Когда мы спросили одну из моделей, что такое форк Jatoba, она уверенно ответила: «Jatoba — это форк PostgreSQL, разработанный компанией Postgres Professional». И таких ляпов — масса. Пока эта проблема не решена, использование ИИ в критических системах требует постоянного контроля со стороны человека или другого ИИ.

Железо снова диктует архитектуру

Мы привыкли, что коммерческие СУБД — это дисковая система, которая кэширует данные в хранят БД на дисках и для скорости обработки кэшируют данные в RAM . Но появление доступной энергонезависимой памяти () может перевернуть эту игру. Если вся база живет в памяти, которая не стирается при выключении, многие классические механизмы СУБД (журналирование, буферизация) придется переизобретать с нуля.

Другой тренд — обход операционной системы

СУБД уже давно превратились в подобие операционных систем. Они сами управляют памятью, процессами, конкурентным доступом. Логичный шаг — дать им прямой доступ к «сырому» железу, минуя прослойку универсальной ОС, как это сделано в Oracle ASM. Это сложно, это требует огромных ресурсов, но за этим будущее высоконагруженных систем.

SQL: язык, который переживет нас всех

Несмотря на все попытки убить SQL или заменить его на специализированные API для разных типов данных, он остается лингва франка работы с данными.

Секрет живучести SQL — в его способности поглощать новые парадигмы. Появился JSON? Добавили операторы в SQL. Нужны графы или геоданные? Они тоже становятся частью SQL.

Oracle показывает правильный путь: не плодить сущности через тысячи функций, а расширять сам синтаксис языка. SQL — это невероятно устойчивая и понятная конструкция. Никаких признаков его смерти нет, он просто адаптируется под новые реалии.

Вызов сообществу

Если мы серьезно говорим об «альтернативном будущем» СУБД, нужно перестать романтизировать «производительность ради производительности» и «нишевую красоту» ради научных докладов. Будущее — платформенное:

• одна СУБД, которая поддерживает смешанные нагрузки;
• один язык, который развивается без развала экосистемы;
• один графический ЕМ, который контролирует железо, ОС и базу;
• один ИИ-слой, который облегчает и ускоряет работу DBA, разработчиков, специалистов технической поддержки и, объясняя свои решения;
• одна цель — быстро и безопасно запускать приложения, потому что именно они, а не СУБД, нужны бизнесу.

В этом смысле «специализированная универсальность» — не оксюморон, а маршрутная карта на ближайшие 5–10 лет. И да, SQL мы оставляем. Мы просто перестаем стесняться его зрелости.