PGConf.Pоссия 2026

Postgres Pro AXE - аналитическая СУБД для работы с большими и гибридными нагрузками. В докладе кратко разберем что из себя представляет продукт Postgres Pro AXE: какие задачи решает, архитектура и основные компоненты, функциональность и примеры использования. Доклад будет полезен архитекторам и разработчикам, которые еще не знакомы с продуктом, которые рассматривают современные решения на базе PostgreSQL для построения хранилищ данных разного объема.

Меня зовут Григорий Новиков, я учусь на ФИТ НГУ и прохожу практику в совместной лаборатории PostgresPro и НГУ — PgLab. Наверняка многие из вас настраивали асинхронную репликацию в PostgreSQL. Возможно, даже каскадную асинхронную. А как насчёт синхронной каскадной? Тут всё просто — её нет. Нам она понадобилась, и мы решили эту проблему: реализовали синхронную каскадную репликацию в PostgreSQL. В докладе я расскажу, зачем она нам понадобилась и как мы её сделали, покажу, где взять патч, как его применить и как настроить синхронный каскад у себя.

Классическая ситуация: в часы пик база данных захлебывается, CPU загружен на 100%, диски простаивают, а в топе запросов висит «мелочь». Привычный мониторинг бессилен: ни долгих транзакций, ни тяжелых выборок, ни очевидных блокировок. Истинная причина просадки остается невидимой Иногда виновником оказываются «горячие блоки». Проблема возникает, когда множество процессов одновременно конкурируют за доступ к одному и тому же блоку. Данные находятся в кэше и читаются быстро, но механизмы защиты памяти не рассчитаны на такой ажиотаж. В итоге время тратится не на полезную работу, а на борьбу за право доступа к странице. Стандартные инструменты Postgres не позволяют локализовать проблему до конкретного объекта базы данных, ставшего узким горлышком. В этом докладе я расскажу: 1. Как возникают «горячие блоки» и почему стандартный мониторинг слеп к этой проблеме; 2. Как я написала собственное расширение, чтобы заглянуть «под капот» базы и увидеть скрытую механику работы с памятью; 3. Как найти таблицу-виновника за пару минут и спасти производительность.

"Бизнес-логика в базе данных - это антипаттерн". Эта мантра передаётся разработчиками из поколения в поколение уже более 20 лет. Причины очевидны: реляционные СУБД плохо масштабируются, а реализовывать сложную бизнес-логику с их помощью неудобно и немодно. Однако у такого подхода есть и сильные стороны: мощь и выразительность языка SQL (и его процедурных расширений при необходимости), а также возможность выполнять вычисления прямо не отходя от данных. Кроме того, в последние годы правила игры начали меняться - особенно с популяризацией распределённых реляционных СУБД и AI-агентов. В докладе попробуем ответить на вопрос: действительно ли бизнес-логике не место в базе данных - или это устаревший архитектурный догмат?