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

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

На этом строится развитие продуктовой экосистемы Tantor. Компания создаёт технологии, которые заметно расширяют привычные для рынка возможности PostgreSQL, а наиболее сложные решения анонсируются в Tantor Postgres после проверок в специализированных продуктах. Это позволяет одновременно решать текущие задачи заказчиков и создавать технологический задел для следующих поколений корпоративных систем.

Во флагманской машине баз данных Tantor XData Gen3 реализованы прорывные для российского рынка технологии для высокопроизводительных корпоративных сценариев. При этом, отдельные технологии для задач, которые выходят за рамки классической архитектуры PostgreSQL, после проверки переходят в Tantor Postgres. Так, в релизе СУБД Tantor Postgres 18 наряду с возможностями PostgreSQL 18 появились новые разработки «Тантор Лабс», ранее созданные для более специализированных продуктов. Один из примеров — Commit Sequence Number, или CSN. При большом количестве одновременных подключений традиционный механизм формирования снимка данных требует учитывать состояние большого числа активных процессов. CSN использует монотонно возрастающий номер, присваиваемый транзакции при фиксации, что позволяет снизить эти накладные расходы.

Рост базы быстро превращается в инфраструктурную проблему: требуется больше дискового пространства, растут объемы резервного копирования и нагрузка на ввод-вывод.

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

В «Тантор Лабс» при разработке Compression Storage Manager исходили именно из баланса, из общего эффекта. CSM сжимает страницы на уровне менеджера хранения при записи на диск, а для приложения таблицы и индексы остаются обычными объектами СУБД. При этом сжимать можно не все подряд, а только те объекты, для которых это действительно оправдано.

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

В Tantor Postgres 18 реализовано около 50 оптимизаций для таких сценариев. Среди них – изменения в оценке кардинальности, полноценный параллелизм, оптимизация работы с виртуальными и временными таблицами, улучшения планирования запросов и работы с репликами.

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

Особенно важно это при переходе на новую версию PostgreSQL. Даже изменения в новых релизах PostgreSQL могут неожиданно влиять на выполнение отдельных операций. Например, в ходе тестирования Tantor Postgres 18 команда обнаружила случаи, когда новые механизмы планировщика ухудшали работу отдельных запросов «1С». Такие изменения приходится разбирать на уровне планов и поведения ядра, исправлять и затем снова прогонять весь нагрузочный сценарий.

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

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

Поставка любой редакции СУБД Tantor Postgres включает в себя Платформу Tantor — передовой графический инструмент для мониторинга и управления любыми СУБД на базе PostgreSQL. В релизе 7.0 появился ИИ-мониторинг, который анализирует состояние экземпляров, выявляет потенциальные проблемы и формирует рекомендации. Это управляемый контур взаимодействия ИИ с СУБД, в котором модель получает необходимый контекст и возможности для диагностики, а система определяет границы её работы.

Tantor Postgres 18 показывает, как меняется подход к развитию корпоративной СУБД. Новые возможности появляются не только внутри основной ветки разработки PostgreSQL. Они возникают из конкретных задач, проходят проверку в специализированных продуктах и на реальных нагрузках, а затем становятся частью основной СУБД.

Tantor XData Gen3 и Tantor Polar позволяют работать с архитектурами для высокопроизводительных систем. Tantor Postgres переносит наиболее востребованные технологии в более широкий круг корпоративных сценариев. Платформа Tantor развивает эксплуатационный контур и добавляет к нему ИИ.

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

Именно сочетание этих двух направлений — глубокой собственной разработки и сохранения совместимости — становится основой развития Tantor Postgres 18 и всей технологической линии «Тантор Лабс».