Базы данных давно являются фундаментом цифровой экономики. От их архитектуры и производительности во многом зависят скорость вывода продуктов на рынок, стабильность сервисов и итоговая стоимость ИТ-инфраструктуры. В мировой практике одним из основных стандартов де-факто, вокруг которого формируются экосистемы серьезных решений, стала открытая СУБД PostgreSQL. В России она используется во множестве корпоративных приложений, есть целый ряд отечественных форков и дистрибутивов. Но у ряда зарубежных компаний есть серьезные прорывные реализации, интенсивно развивающие Postgres (например, Aurora, AlloyDB и Neon, об этом ниже), а у российских этого почему-то не наблюдается. Это противоречие между массовым использованием PostgreSQL в нашей стране и отсутствием технологического прорыва задает остроту сегодняшней повестки отечественного СУБД-строения.

Глобальные тренды рынка СУБД

Итак, на мировом рынке Postgres уже давно перестал быть просто базой данных. Это уже платформа, вокруг которой строятся облачные сервисы, инструменты для работы с искусственным интеллектом и новые модели монетизации. Основные инвестиции, инновации и сделки на мировом рынке сосредоточены вокруг Postgres и его производных – это подтверждается крупнейшими приобретениями (Neon, CrunchyData) и запусками новых сервисов (HorizonDB) именно в этой нише, что подтверждается  в свежем аналитическом обзоре Энди Павло (Andy Pavlo), одного из ведущих мировых экспертов по СУБД. 

Главный вектор — не точечные улучшения, а архитектурные прорывы с сохранением совместимости, не просто добавление новых функций, а создание масштабируемых cloud-native решений (разделение вычислений и хранения, бессерверность). Успешные мировые проекты (Aurora, AlloyDB, Neon) кардинально меняют архитектуру, сохраняя совместимость с ядром Postgres и его экосистемой, что снимает барьер для миграции.

Следующий вектор развития – тесная интеграция с ИИ: вендоры добавляют поддержку векторных форматов хранения, оптимизируют поиск по Embedding-моделям, стандартизуют интеграции с ИИ через MCP (Model Context Protocol), учатся одновременно обслуживать транзакции и аналитические запросы.

Еще один заметный тренд – перенос баз данных в облако. Экономика сама по себе смещается в сторону сервисной (подписной) модели и платформенности, рынок начинает ценить не ядро СУБД само по себе, а удобный сервис с автоматическим масштабированием, управлением, миграциями и встроенными защитными механизмами. Успешные мировые компании продают именно предсказуемую стоимость владения и снижение операционных издержек, а не лицензии. Это требует определенного культурного сдвига у вендоров и заказчиков. Лидеры рынка демонстрируют здесь разнообразие стратегий. Amazon превратил Postgres в сервис Aurora и сделал его полноценным облачным продуктом. Google с AlloyDB сделал акцент на рост производительности и позиционирует его как решение нового поколения. Китайские гиганты Alibaba и Huawei идут в сторону гибридных систем, способных одновременно работать с транзакциями и аналитикой. Microsoft до недавнего времени делала ставку на масштабирование с использованием расширения Citus, но в конце 2025 года анонсировала новый сервис Azure HorizonDB, очень похожий на решения от Amazon, Google и Alibaba.

Пример совсем новой волны – компания Neon, которая предложила и вовсе бессерверную модель работы с Postgres. Фактически это облачный сервис, где ресурсы масштабируются автоматически, без всяческих усилий со стороны пользователя в части серверов и инфраструктуры. Именно такой подход сделал стартап привлекательным для инвесторов, которые приобрели его за $1 млрд. Другие игроки также заняли свои ниши: CrunchyData развивает Postgres для государственных и высокозащищенных сред, а EnterpriseDB после многих лет работы на рынке миграции из Oracle в собственный форк PostgreSQL, теперь делает ставку на интеграцию с искусственным интеллектом.

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

Российский контекст

Можно констатировать, что в России Postgres стал стандартом по умолчанию: его выбирают для бизнес-приложений, государственных систем, корпоративных сервисов. На рынке появилось множество форков и дистрибутивов, однако почти все они двигаются параллельными курсами в одном направлении – добавляют точечные функции, не меняя исходной архитектуры. Это создает иллюзию разнообразия, хотя на деле большинство решений повторяют друг друга.

А главная проблема – отсутствие настоящего cloud-native Postgres. Архитектуры с разделением вычислений и хранения в нашей стране пока не реализованы, а попытки масштабировать систему через собственные доработки часто упираются в несовместимость с прикладным софтом, который привык к поведению “обычного” Postgres. Разработчики вынуждены выбирать между производительностью и доработкой приложений под уникальные “фичи” коммерческих форков – а это во многом ложный выбор, мировые вендоры уже научились обходить этот компромисс и находить эффективные решения.

Технологический разрыв становится особенно заметным в облаках и ИИ-сценариях. Пока западные и восточные игроки предлагают Postgres как эластичный сервис для смешанных нагрузок, российские проекты ограничиваются базовым функционалом и локальными оптимизациями. В результате отечественный рынок активно использует Postgres, но не формирует прорывных решений, способных конкурировать на глобальном уровне.

Первый барьер – совместимость. Любая радикальная доработка Postgres ведет к риску обратной несовместимости с существующими бизнес-приложениями. Для компаний, где на СУБД завязаны десятки и сотни систем, это означает огромные издержки при миграции.

Второй вызов – дефицит инженерных ресурсов. Разработка масштабируемой cloud-native СУБД требует команды мирового уровня, способной работать с архитектурой десятки лет подряд и с прицелом на десятки лет вперед. В России, безусловно, есть отдельные сильные группы, но нет критической массы разработчиков, готовых тянуть такие проекты.

Третья проблема – экономика. Западные вендоры делают ставку на эффективное использование ресурсов, гибкое масштабирование и прогнозируемую стоимость владения. У нас же фокус смещен на функциональность и галочки в чек-листах и батл-картах, в то время как оптимизация затрат часто остается на втором плане.

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

Перспективы и стратегии

Выход из технологического тупика возможен только через качественный архитектурный скачок. На практике это очень сложная задача, однако именно здесь есть шанс для российских игроков не просто копировать западные практики постфактум, а встроиться в тренд в реальном времени. Наиболее интересное направление – разделение вычислений и хранения. Такой подход в мире уже реализован в облаках, и он доказал свою эффективность. Это дает масштабируемость без сложных компромиссов, позволяет запускать смешанные нагрузки и открывает путь к новым сценариям, включая ИИ. Разработки уже ведутся: третье поколение российской машины баз данных Tantor XData как раз строится по модели Disaggregated Compute and Storage: это даст серьезный прирост производительности и сделает систему ближе к Oracle Exadata. 

Второе направление – развитие HTAP-подхода, когда одна база способна одновременно обслуживать транзакционные и аналитические запросы. Такой подход полезен компаниям, работающих с большими потоками данных (десятки или сотни терабайт). Речь идет не о смешивании различных СУБД путем их интеграции, а о доработке PostgreSQL таким образом, чтобы она могла работать в том числе как MPP-система (Massive Parallel Processing).

Третья стратегическая линия – платформенность. Отдельная СУБД больше не воспринимается рынком как самостоятельная ценность. Заказчикам нужен единый интерфейс для управления всеми базами, миграциями, интеграциями, а также контроль данных в аспекте информационной безопасности. Такой хаб становится центром ИТ-инфраструктуры и снижает барьеры перехода к облачным сервисам.

Наконец, неизбежен переход от приобретения бессрочных лицензий к подписной модели. Мир движется в эту сторону, и российские решения, чтобы оставаться конкурентоспособными, должны предложить сервис в том же формате. Это не только вопрос экономики, но и способ встроиться в привычную для бизнеса логику потребления ИТ.

Выводы

Российский рынок баз данных оказался в двойственном положении. С одной стороны, PostgreSQL надежно закрепился в корпоративных системах, с другой – его архитектурное развитие застопорилось. Чтобы изменить ситуацию, нужны не косметические улучшения, а стратегические шаги: переход к разделению вычислений и хранения, развитие HTAP-подхода, создание единой платформы управления и движение к сервисной модели. Архитектурные тренды уже хорошо прослеживаются, и правильные инвестиции в сloud-native и ИИ-ориентированные решения могут вывести отечественные СУБД на новый уровень. Главный шанс для отечественных игроков – использовать представившееся окно возможностей.