Крупные вендоры все чаще говорят не столько о СУБД, сколько о платформах данных. Для корпоративного заказчика это маркетинг или действительно смена сути?

Вадим Яценко: Движение в сторону платформенности действительно есть: вендоры стараются строить экосистемы, а не предлагать отдельные точечные решения. В каком-то смысле практически любую современную СУБД можно назвать платформой, потому что вокруг нее существует множество расширений, дополнительных движков и инструментов. Сейчас этот процесс выходит на новый уровень из-за искусственного интеллекта. Он меняет требования к работе с данными, растут объемы информации, появляются новые и смешанные нагрузки. Поэтому СУБД постепенно приходится брать на себя больше функций и становиться частью более широкой платформы.

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

А сейчас рынок движется обратно к универсальным СУБД?

Вадим Яценко: Я бы не называл это обратным движением. Скорее, развитие идет по спирали. Раньше платформу собирали из разных движков с разными форматами хранения и зачастую разными SQL-диалектами. Каждый из них хранил данные по-своему, поэтому информацию приходилось копировать и преобразовывать при переносе между системами.

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

В Tantor мы поэтому выбрали несколько другой путь. Нам ближе подход классических enterprise-СУБД общего назначения, которые решают транзакционные и аналитические задачи внутри единой архитектуры. Мы хотим развивать сам PostgreSQL и его внутренние механизмы, а не превращать его в оболочку, внутри которой работают несколько самостоятельных систем.

При этом мы не отгораживаемся от остального рынка. Есть открытые форматы, lakehouse, разные расширения и аналитические движки, с ними можно работать, если заказчику это требуется. Но стратегическим направлением для себя мы считаем именно развитие самой СУБД.

PostgreSQL окружает огромная экосистема расширений и внешних компонентов, которые позволяют закрывать многие его архитектурные ограничения. Почему, на ваш взгляд, этого подхода недостаточно для дальнейшего развития корпоративных СУБД?

Вадим Яценко: Вокруг PostgreSQL, действительно, сформировалась огромная экосистема. Есть очень крупные и зрелые расширения вроде PostGIS, которые добавляют СУБД целые классы возможностей. Еще важнее накопленная вокруг PostgreSQL экспертиза: выросло целое поколение инженеров и разработчиков, для которых это привычная технология. В России PostgreSQL фактически стал стандартом, и такую инерцию нельзя игнорировать.

Но при этом у PostgreSQL есть архитектурные ограничения, в частности связанные с историей развития системы. Многие базовые решения появились десятилетия назад, когда объемы данных и требования к СУБД были совершенно другими. За это время радикально изменились нагрузки, инфраструктура и само представление о работе с данными. Один из способов компенсировать эти ограничения — выносить отдельные задачи во внешние системы. Например, аналитическую обработку можно перенести из транзакционного PostgreSQL в отдельную аналитическую СУБД вроде Greenplum. Появляются и варианты интеграции PostgreSQL с аналитическими движками вроде DuckDB. Но подключение дополнительного движка само по себе не дает PostgreSQL соответствующих архитектурных возможностей. В результате мы снова получаем платформу из нескольких компонентов, между которыми необходимо распределять данные и задачи.

Мы в Tantor выбрали другой путь: хотим развивать возможности самого PostgreSQL и для этого достаточно серьезно меняем его архитектуру. Это сложнее для разработчиков, зато позволяет заказчикам работать в рамках единой СУБД, не собирая необходимые enterprise-возможности из нескольких самостоятельных движков.

Может ли крупный бизнес быть уверен, что вы на долгие годы сможете сохранить баланс между архитектурными инновациями, совместимостью с основной веткой и поддержкой крупных внедрений?

Вадим Яценко: Вы наверняка знаете, что в PostgreSQL есть целое «кладбище форков». Огромное количество проектов умерло именно потому, что разработчики не смогли найти баланс между собственными изменениями и развитием основной ветки. Если сильно уйти в сторону и потерять возможность оперативно переносить изменения из open source PostgreSQL, поддерживать собственный код становится все сложнее. В какой-то момент продукт остается на старой версии и постепенно попадает в технологический тупик.

Поэтому связь с сообществом принципиальна. Вендор должен очень хорошо понимать, как работает PostgreSQL-сообщество, следить за основной веткой и возвращать в нее свои наработки. Это и развивает PostgreSQL, и снижает дальнейшую стоимость поддержки собственных изменений. Не менее важно, кто именно вносит эти изменения. Нужны разработчики, которые хорошо знают код PostgreSQL, работают с сообществом и понимают, на каком уровне можно вмешиваться в архитектуру. Open source не означает, что можно просто взять исходный код, произвольно его переписать и получить жизнеспособную корпоративную СУБД.

Я сам занимаюсь PostgreSQL около 16 лет. Наша команда давно находится внутри профессионального сообщества и отлично понимает, как устроено развитие проекта. Для заказчика это один из важнейших критериев выбора коммерческой версии PostgreSQL: смотреть стоит не только на список функций, но и на людей, которые ее создают, на их опыт и вклад в развитие основной версии PostgreSQL.

Одно из фундаментальных ограничений PostgreSQL связано с масштабированием. Почему традиционного шардинга для тяжелых корпоративных систем уже недостаточно?

Вадим Яценко: Классический способ горизонтально масштабировать PostgreSQL довольно очевиден: если одного узла недостаточно, делаем несколько и распределяем между ними данные. На этом принципе, например, строятся решения с шардированием PostgreSQL. Такой подход работает, но добавляет задачи, связанные с распределением и перераспределением данных между узлами, дальнейшим масштабированием и эксплуатацией распределенного кластера.

Есть более перспективное архитектурное направление — разделение уровней вычислений и хранения. Один из самых заметных примеров — Amazon Aurora. Я хорошо помню ее появление на рынке в 2015 году. Amazon фактически сказал: «Давайте изменим саму архитектуру СУБД: разнесем вычисления и хранение и за счет этого получим совсем другой уровень масштабирования». На старте Aurora могла автоматически масштабировать хранилище до 64 ТБ. Сейчас эта цифра не выглядит чем-то невероятным, но для того времени это действительно был прорыв.

Потом в том же направлении начали двигаться другие крупные игроки: появился Google AlloyDB, свои решения развивал Microsoft, возник open source-проект Neon. Облачные компании во многом первыми пошли этим путем по прагматичной причине: когда у тебя огромное количество инсталляций, каждая лишняя копия данных или неэффективно используемый ресурс превращается в очень большие деньги.

Но довольно быстро выяснилось, что разделение compute и storage дает больше, чем экономию. Можно независимо масштабировать вычислительные ресурсы и хранение, строить более эластичные системы, добавлять новые способы обработки данных. Около двух лет назад мы в Tantor выбрали разделение compute и storage одним из базовых направлений развития нашей СУБД. Среди российских PostgreSQL-вендоров мы первыми поставили инженерный вопрос настолько серьезно, и проделанная работа уже воплотилась в машине баз данных Tantor XData Gen3, работающей на распределенной СУБД Tantor Polar.

И эта же архитектура оказалась подходящей для искусственного интеллекта?

Вадим Яценко: Да, причем это довольно интересная история. Разделение вычислений и хранения начали развивать совсем не потому, что все заранее предвидели нынешний бум ИИ. В облаках это прежде всего было способом эффективнее масштабировать PostgreSQL и снижать стоимость инфраструктуры. А потом оказалось, что та же архитектура очень хорошо ложится на ИИ-нагрузки.

У ИИ-нагрузок есть важная особенность: их поведение сложнее предсказывать. Агенту может понадобиться обратиться к базе данных неизвестное заранее количество раз, выполнить разные запросы, получить дополнительный контекст. Кроме того, рядом с традиционной транзакционной обработкой возникают аналитические задачи, векторный поиск и другие способы работы с теми же данными. Возможность независимо управлять вычислительными ресурсами и хранением в такой ситуации становится особенно полезной.

Дальше возникает задача эффективно хранить и обрабатывать сами данные для ИИ. Отсюда появляются векторные расширения PostgreSQL, векторный поиск, развиваются аналитические возможности. Получается, что искусственный интеллект уже начинает влиять не только на приложения вокруг СУБД, но и на ее архитектуру.

Но зачем, например, векторный поиск компании, у которой основная корпоративная система — та же 1С?

Вадим Яценко: Даже 1С сейчас активно идет в искусственный интеллект и разрабатывает собственные модели для своих задач. Это хороший пример того, почему такие технологии быстро перестают быть узкоспециализированными. Возьмем разработку в 1С. Написание запросов может быть сложной задачей, особенно для не очень опытного разработчика. При этом, когда говорят «1С плохо работает», частенько проблема не в самой 1С, а в том, как написано приложение и какие запросы оно выполняет. Если ИИ может помочь разработчику сформировать более качественный запрос или пользователю получить нужную информацию, пользовательский опыт существенно меняется.

Следующий этап — развитие агентов. Я недавно вернулся с WAIC 2026 — крупной выставки по искусственному интеллекту в Шанхае. Практически у всех крупных компаний — Alibaba, Inspur, Huawei — лейтмотивом был Agentic AI. Разговор давно идет не о простых чат-ботах, а именно об ИИ-агентах, которые становятся помощниками бухгалтера, юриста, аналитика. А любому агенту нужны данные. Если это значимые финансовые, бухгалтерские или производственные данные, они, скорее всего, находятся в СУБД. Для работы с ними могут потребоваться векторный поиск, графовое представление и другие способы обработки. Поэтому вопрос «зачем бухгалтерской базе векторы?» через некоторое время, думаю, вообще перестанет возникать.

Источник: TAdviser.

Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.