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

О том, почему мы неизбежно движемся к созданию новых «монстров» (в хорошем смысле), и какие архитектурные сдвиги нас ждут, мы поговорили с руководителем отдела технического консалтинга Postgres Professional Марком Ривкиным. Данный материал представляет собой частное мнение автора, основанное на его многолетней практике; этот взгляд является независимым.

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

«Раньше, когда к нам приходили за аналитикой, мы честно говорили: "Извините, ребята, идите в Greenplum". Ванильный Postgres и его форки всегда были заточены под OLTP. Сейчас мы встроили возможность работать с аналитической нагрузкой прямо в Postgres Pro Enterprise».

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

• администраторов (DBA): огромный пласт рутинных задач по мониторингу, поиску узких мест и настройке можно переложить на ИИ.

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

• техподдержки: ИИ может анализировать логи, находить аналогичные инциденты в базе знаний и предлагать решения, ускоряя разрешение проблем.

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

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

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

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

Марк Ривкин

Руководитель отдела технического консалтинга Postgres Professional

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

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

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

• одна СУБД, которая поддерживает смешанные нагрузки;

• один язык, который развивается без развала экосистемы;

• один графический ЕМ, который контролирует железо, ОС и базу;

• один ИИ-слой, который облегчает и ускоряет работу DBA, разработчиков, специалистов технической поддержки и, объясняя свои решения;

• одна цель — быстро и безопасно запускать приложения, потому что именно они, а не СУБД, нужны бизнесу.

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