Postgres по-русски: где наши Aurora, AlloyDB и Neon?

06.02.26

База данных - Администрирование СУБД

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

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

 

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

Итак, на мировом рынке 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 и ИИ-ориентированные решения могут вывести отечественные СУБД на новый уровень. Главный шанс для отечественных игроков – использовать представившееся окно возможностей. 

Вступайте в нашу телеграмм-группу Инфостарт

Tantor Postgres 1С СУБД базы данных cloud-native

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бухгалтерский учет Бесплатно (free)

После миграции с MS SQL на PostgreSQL закрытие месяца в 1С:ERP стало идти 8 часов вместо 12 минут. Рассказываем, как мы нашли причину в оценке Hash Join, которую планировщик завышал в миллионы раз, и как исправили её так, что проблемный запрос теперь выполняется за 18 секунд вместо часа.

19.10.2026    1021    Tantor    0    

10

Администрирование СУБД HighLoad оптимизация Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны — какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.

01.10.2026    1516    Tantor    6    

18

DevOps и автоматизация разработки Администрирование СУБД Групповая разработка (Git, хранилище) Разработчик 1С 8.3 Абонемент ($m)

В корпоративных инсталляциях «1С:Предприятие 8.3» под управлением PostgreSQL всё чаще проявляются архитектурные пределы масштабирования: рост числа пользователей, обязательная маркировка, плотный поток API-интеграций и высокая стоимость простоя. Вводная часть цикла разбирает ключевые факторы современной эксплуатационной нагрузки и формирует инженерную методологию эволюционной модернизации без остановки продуктивного контура. Материал основан на практическом кейсе «Торговый контур» и показывает, как определить целевые метрики (p95, MTTR, APDEX), выстроить наблюдаемость, стабилизировать работу кластера и подготовить инфраструктуру к дальнейшему масштабированию. Публикация задаёт фундамент для последующих частей, посвящённых телеметрии, оптимизации PostgreSQL, CI/CD и архитектурному росту.

1 стартмани

10.09.2026    1576    Ninel_S    0    

6

HighLoad оптимизация Администрирование СУБД Разработчик 1С:Предприятие 8 1С:ERP Управление предприятием 2 Бесплатно (free)

В рамках 18 релиза СУБД Tantor Postgres мы рассказывали об оптимизациях, которые помогают планировщику сделать более точный выбор между Nested Loop и Hash Join. В следующем релизе у нас планируются оптимизации, которые позволят ускорить выполнение как Nested Loop, так и Hash Join. Сегодня мы расскажем об одном из таких методов - фильтре Блума.

31.08.2026    6175    Tantor    3    

18

Администрирование СУБД Системный администратор Разработчик 1С 8.3 Бесплатно (free)

Мы подготовили для сообщества Infostart.ru практическое занятие, в котором каждый желающий сможет: научиться собирать реальные данные о процессах кластера 1С; выявлять «перестарков» — процессы старше периода и без соединений; выполнять безопасный перезапуск (с dry-run и подтверждением); настраивать автоматическую проверку через systemd на Linux; отправлять уведомления (Telegram, почта) при обнаружении проблем; работать с логами, ротацией, профилями кластеров и конфигурацией; развернуть полноценный учебный проект AdminClusterMonitor у себя в тестовой среде.

30.08.2026    1776    Ninel_S    2    

6

Администрирование СУБД Системный администратор 1С:Предприятие 8 Бесплатно (free)

На infostart.ru вышел разбор Ивана Недомолкова «Сервер 1С падает: настройка сбора дампов (logcfg.xml), лимиты памяти и передача дампа в поддержку» - это хорошая инструкция, как ловить и разбирать падение rphost постфактум: logcfg.xml, procdump, анализ дампа. Но там нет ответа на вопрос «а почему кластер вообще прибил процесс сам, ещё до всякого краша». Мы дополняем разбор тремя сводными таблицами лимитов памяти и автомасштабирования кластера - и заодно фиксируем, чем в этой части лицензия ПРОФ урезана относительно КОРП.

12.08.2026    2538    Ninel_S    5    

6

Администрирование СУБД Системный администратор Разработчик Бесплатно (free)

5,5 тысячи пользователей в единой базе 1С, розница в режиме 24/7 и SLA 99,98% – в таких условиях любая авария быстро превращается в очереди на кассах, потерю денег и давление со стороны бизнеса. Показываем, как выстроить процесс аварийно-восстановительных работ: от первых алертов и базового скрининга системы до подключения команды, проверки гипотез и дебрифа после инцидента. Разбираем, как метрики, дашборды, техжурнал, Zabbix, Prometheus, Grafana, Telegram-боты и скрипты помогают не гадать, а быстро находить причину проблемы. На реальных авариях объясняем, почему «быстро» не должно означать «рискованно», как работа над ошибками снижает панику и почему каждая авария может сделать систему надежнее.

11.08.2026    3456    jul.dolganova    9    

24
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. SerVer1C 1146 06.02.26 13:48 Сейчас в теме
Многие отечественные продукты - это иностранные или опенсорсные продукты, но со своим шильдиком и конской ценой.
2. VSvintsov1 20.02.26 11:58 Сейчас в теме
все же сомнительны перспективы Postgresql - как только "железный занавес" упадет, то кому Postgresql будет нужен, по ценам сопоставимым с привычными серверами баз данных ? Тем более что автор в статье упоминает - нет в РФ критической массы специалистов способных без госбюджетных вливаний развивать имеющееся.
Для отправки сообщения требуется регистрация/авторизация