Конференция PGConf.Россия 2026 прошла 23-24 марта в московском Центре Международной Торговли, а на днях для участников выложили видео, презентации, ну а фото вообще доступны всем. В этом году конференцию посетило примерно 1300 очно и 800 заочно. По сравнению с прошлой конференцией она немного подросла: на PGConf.Russia 2025 было 1120 очных, в сумме около 2 тыс. человек. Конференция претерпела лёгкий ребрендинг: PGConf.Russia => PGConf.Россия (переход плавный: PGConf.СПб 2025, а не SPb).

Число стендов достигло 15: 11 по основным продуктам Postgres Professional, 4 пратнёрских: Скала^р, Selectel, ФОРС и Киберпротект. А ещё отдельная территория была выделена стендам издательств: ДМК Пресс, Бумба и ИД Питер.

Доклады на этот раз проходили в 4 залах (на прошлой - в 3): главный - сдвоенный и 3 зала поменьше. Один из них был отдан целиком Postgres Pro. Ещё в 2 залах проходили мастер-классы.

Мастер-классы были в том числе марафонские:

Алексей Лесовский, руководитель отдела разработки Postgres Professional 240 минут - 4 часа! - учил мониторингу PostgreSQL от метрик до дашбордов с pgpro-otel-collector. Напомним, что у Алексея вышла книга Мониторинг PostgreSQL в издательстве Бумба.

Старший инженер Postgres Professional Денис Гидин был скромней: 3 часа учил, как работать с расширениями Postgres Pro Enterprise для оптимизации запросов. А может и не скромнее: он ещё и учил 2 часа (т.е. в сумме 5 ч.) Postgres Pro AXE - колоночному векторному сверхбыстрому инструменту для аналитики.

Кстати, 3-часовые классы на PGConf.Russia раньше встречались. Но не часто: в 2020 Антон Дорошкевич, руководитель ИТ в ИнфоСофте, учил настраивать PostgreSQL для 1С.

Это всё, конечно, не значит, что полумарафонские и даже короткие не заслужили упоминания. Создание цифрового двойника 1С в экосистеме Postgres Professional на основе AXE, Tengri и BI.Qube Дмитрия Поликовского и Дмитрия Понкратенко (оба BI.Qube, архитектор перспективных платформ и директор по развитию дополняли и класс Антона Дорошкевича (по 1С) и Дениса Гиндина (по AXE).

Но были и ещё дополняющие мастер-класс доклады: Особенности построения аналитики из 1С:Предприятие в Postgres Pro AXE и Tengri Data - тоже от BI.Qube. На этот раз - Борис Бондарев, главный архитектор.

А Pg_probackup3 и архив WAL - мастер-класс Евгения Гарбуза, старшего инженера по тестированию Postgres Professional, был дополнен докладом Бэкапы PostgreSQL и как с ними не накосячить Софьи Копиковой, разработчицы программного обеспечения Postgres Professional. Или лучше так: мастер-классы дополняли доклады - редкий случай, когда в русском языке, богатом падежами, непонятно, кто кого дополнял. Главное, что дополнили друг друга.

Но вернёмся к самому началу.

Открываются конференции всё фееричней: теперь ударом в бубен не ограничиваются, теперь в качестве увертюры мини-шоу:

Олег Бартунов, президент Postgres Professional, ведёт летосчисление Postgres не с основания открытого проекта в 1996 (в планетарном масштабе будут отмечать на PGConf.dev 2026 в Ванкувере): 40 лет назад появилась статья, излагающая принципы Postgres, а потом, около 30 лет назад - появилась и сама база приблизительно в том виде, как сейчас.

Сам же он вступил в сообщество Postgres 8 сентября 1995. И напомнил, что 1-й коммит был принят 9 июля 1996. Но главное, сказал Олег, что за 40 лет не стал музеем. И он, но не один приложил к этому руку. "Нам с Федей [техдиром Фёдором Сигаевым] удалось расшатать границы реляционной теории". "Без русских Postgres не будет Postgres" - цитирует он другого Postgres-классика - Брюса Момджана. Кстати, последнее время уже на нескольких Postgres-ивентах в свете софитов появляется Postgres-классик Вадим Михеев.

Олег, однако, о прошлом говорил мало, в основном о будущем - тоже, желательно, немузейном. Например, о "притяжении (гравитации) данных". Агенты ИИ придут туда, где живут данные. А они живут в Postgres. Будущие [главные] пользователи постгреса не люди, а агенты. И "он не должен стать лучшим вычислителем, он должен стать дружественным к внешним вычислителям".

Часть выступления о более приземлённых вещах относилась к HTAP. Олег считает, что HTAP не равно сумме OLTP+OLAP. Потому, что это способность обрабатывать запросы с контролируемой свежестью. "Пока нет таких СУБД чтобы могли сочетать операционность и контроль расстояния до знания, которое получается из этих операционных данных. "Сделай мне данные, которые не протухли за 1 день" или за 20 минут. Энтерпрайз начал понимать, что архитектура, где между данными и аналитикой мостик ETL, - это путь в никуда. ИИ-агент не будет думать и сомневаться, для него неконтролируемая свежесть губительна."

Руководитель образовательных программ Postgres Professional - Павел Лузанов, начал свой традиционный доклад не совсем традиционно: "известно, что приём изменений в 19-ю версию ещё не [был] закончен. О чём же я буду докладывать?" И начал он с истории патча по секционированию (разделение, слияние секций). Да, патч со своей историей: об этом патче он говорил 2 года назад и сейчас даже использовал слайды с того доклада, исправив 2024 на 2026. Тогда этот патч приняли, потом откатили, а сейчас опять приняли. Ну а дальше говорил о патчах с судьбой вполне обыденной.

Мы в своих Postgresso не обделяем обзоры Павла вниманием, поэтому здесь пересказывать не будем. Вот ссылка на самый свежий на хабре: PostgreSQL 19: Часть 4 или Коммитфест 2026-01.

Один из самых технологичных, из собравших битком упакованную аудиторию из 2 соединённых конференц-залов, был доклад:

Patroni на максимум: инженерные рецепты из OZON для тех, кто хочет спать спокойно.

Григорий Смолкин и Дмитрий Васильев, эксперт по разработке информационных систем и ведущий инженер инфраструктурных сервисов соответственно, оба Ozon. Докладывали они, часто сменяя друг друга - симпатичный формат. И предуведомили: "все ситуации произошли “на живую”, то есть решения были приняты, чтобы разрулить ситуации, этими решениями мы и делимся".

Им удаётся спать спокойно при 20 000 кластерах Patroni (50 000 нод, бэкап - wal-g в S3). Но для хорошего сна сначала надо хорошенько потрудиться. Каждый инцидент - повод для нового автоматического чекера (checker) или гарда (guard). Чекеры выводят из балансировки больные ноды, а гарды чинят кластер. Всё это отправляется в Patroni-сообщество. Вот такие чекеры, гарды и новые теги укрепляют сон:

• checker lag - реплика живёт в прошлом,

• checker pooler - пулер мёртв, а Patrini не знает,

• checker last_seen - потеря связи с DCS

• тег nostream,

• nosync checker,

• vacoom_truncating - невидимый убийца реплик,

• GuardInit - нода Шрёдингера,

• Guard DC - zone affinity,

• SlotGuard - спасение диска,

• Guard IoReadWrite - когда не работают таймауты.

Итак, обезопасили этапы:

1. Тег «noloadbalance»: убираем ноду из балансировки.

2. Safe shutdown: выключение ноды без жертв.

3. Safe startup - возвращение ноды в строй.

4. Safe clone – наливка ноды.

5. Checkers – автоматическая защита от проблем.

6. Guards – проактивная защита кластера.

Результат трудов: 0 ночных звонков при 20 000 кластеров.

О разработке и внедрении автоматизированных моделей беспилотных парусников для экологического мониторинга с применением PostgreSQL рассказал преподаватель КТ МТУСИ Игорь Тот.

Яхты эти пластиковые, длиной 1 м с очень низким центром тяжести. Уместится в них Postgres? И что он, кстати, делает на яхте?

А всё для науки. Чтобы привлекать студентов и даже школьников. Яхты НЕ радиоуправляемые. Маршрут от каждой точки до следующей прописан средствами Postgres. В команде корабля: процессор Repka-Pi 4 Optimal, датчики параметров воды и другие.

Postgres не даст потеряться данным при внезапной разрядке аккумулятора. Среди членов экипажа - PostGIS-штурман. Паруснику надо рассчитывать галсы, и движется он не по прямой. Как ни удивительно, и рулём, и парусами, и ещё много чем управляет Капитан Postgres.

Модель на фото - настоящая автономная научная станция, способная принимать решения “на борту”.

Аналитическое расширение, реализующее базовые алгоритмы машинного обучения в среде PostgreSQL - доклад Натальи Графеевой, доцента ИТМО и Александры Сухотиной, студентки магистратуры ИТМО.

В прошлом году, на PGConf.Academy 2025 Наталья рассказывала о жизни Postgres внутри академической, преподавательской среды - это было интересно. Наталья соавтор книги Основы технологий баз данных издательства ДМК Пресс.

Здесь докладывала, конечно, Александра Сухотина, это педагогично. Александра не просто одна из студенток. Она победительница конкурса по Postgres Pro олимпиады «IT-Планета 2024».

В самом докладе есть уточнение: участники проекта не только Университет ИТМО (впрочем, на их сайте сказано, что ИТМО это больше, чем университет), но и Высшая Школа Цифровой Культуры (при ИТМО), а также СПбГУ.

Типичный конвейер машинного обучения: Данные в БД -> Выгрузка -> Python/R -> Результаты в БД. И типичные проблемы: трафик и потеря контроля над данными за контуром СУБД (для медицины и финансов). Поэтому алгоритмы ML реализовали внутри PostgreSQL.

Реализовали на чём?

Рассматривали PostgresML (Rust+Python, воркеры), Apache MADlib (Python, C++ внутри процесса СУБД). Они не подошли, как я понял, главным образом из-за того, что требуют права суперпользователя. А PL/Python сочли небезопасным для СУБД. Поэтому реализовали всё на чистом PL/pgSQL.

Поскольку проект университетский, то на нём студенты обкатывали разнообразные алгоритмы. Например, в kNN реализовали:

• метрики расстояния: Евклидово, Манхэттенское, Косинусное (для разреженных данных);

• взвешенное голосование: близкие соседи имеют больший “вес”;

• смешанные данные: одновременная работа с числами и категориями.

А в результате университетский проект оформился в самодостаточный и уже оттестированный пакет, где есть предобработка, линейная и полиномиальная регрессия, kNN, градиентный спуск, расчет ошибок.

YMatrix Domino: Design Considerations, Trade-offs, and Implementation of In-Database Stream Processing - Яо Яндун (Yandong Yao), гендир и сооснователь Ymatrix рассказывает о плодах примерно 5-летней работы над проектом стриминговой версии Postgres. Сам Яо, будучи значимой фигурой в Greenplum (глава пекинского R&D-центра), собрал спецов ещё и из Alibaba, Tencent и других ИТ-гигантов.

Конвейеры стриминга слишком сложно устроены - данные проходят через 5 программных слоёв. Короче, хотелось бы обойтись без Apache Flink, Spark, Kafka и им подобных. Но обработка внутри базы тоже не фунт изюма. В Domino делаются уловки на многих этапах обработки запроса. Главное направление в эффективной обработке - инкрементальные вычисления. В плане запросов появляется дельтаплан (DeltaPlan) - он отражает инкрементальную работу с данными.

Яо также объяснил, почему нельзя обойтись материализованными представлениями вместо стриминга. Признался: пока не всё работает:

• MIN/MAX не поддерживаются если в таблице есть UPDATE/DELETE.

• Оконные функции пока не поддерживаются.

• А также CTE/Having/GroupingSet и некоторая другая функциональность.

Задававшие вопросы расширили эту тему: стриминговые таблицы в Domino не будут работать со своими unlogged и foreign собратьями, так как этой системе требуется информация от WAL.

Но всё же: есть работающая PostgreSQL Streaming Computation Model, в PostgreSQL есть все составляющие, чтобы превратить её в стриминговую СУБД, а сам язык SQL уже становится стриминговым. И планы у Яо большие.

pGenie: Генератор кода по схеме и запросам по методологии DB-First

Докладчик - Никита Волков, архитектор codemine.io и автор популярных проектов на Haskell, например:

• hasql - один из двух основных драйверов PostgreSQL для Haskell, используется в проектах PostgREST, Unison, Integrated Haskell Platform;

• refined - библиотека рафинированных типов данных, портирована другими людьми в языки Scala, Idris, PureScript;

• stm-containers - библиотека конкурентных lock-free структур данных.

К БД-центричной среде программирования он пришёл не сразу. Сначала понял, что только с SQL-запросом далеко не уедешь - запрос надо хранить вместе с параметрами и результатом. Дальше, кроме синтаксической проверки нужна и семантическая - например, ссылается ли запрос на существующие таблицы и колонки.

Потом понял: миграции - лучший способ описать структуру БД. Миграции + Запросы = API БД. Редактируем не код, а миграцию, и что на сервер Postgres можно взглянуть как на микросервис - со своим API. И что схема БД - всему голова.

В подходе DB-First схема - единственный источник правды. Типизация генерируется из схемы. Миграции теперь явные и контролируемые.

Расширяемость и гибкость там за счёт расширений - генераторов в экосистеме. Пока они работают только для Haskell и Rust, написаны на экзотическом языке Dhall. Генератор Java в разработке. Но, используя расширения, можно легко обучить pGenie любым языкам. К чему автор и призывает аудиторию. Для этого он и отдал всё в опенсорс. Сайт: pgenie.io, гитхаб: pgenie.

Интересная тема: синергия ИИ и pGenie. LLM пишет запрос на SQL, а pGenie верифицирует и типизирует. Схема - идеальный контекст для ИИ: отсюда точные подсказки, правильные имена, корректные типы. Итого - максимальная скорость разработки, и надёжность.

Никита честно сказал: примерные аналоги есть: sqlc, SQLDelight, JOOQ. И представил табличку, где у кого преимущества. Важно, что pGenie ориентирован только на Postgres, не несёт лишнего груза. И он расширяем.

Статья автора доступна на хабре: Мой 14-летний путь отказа от ORM: череда инсайтов, приведшая к созданию SQL-First кодогенератора для PostgreSQL.

Бизнес-логика в БД: Тяжёлое наследие 90-х или архитектура будущего? - Максим Грамин, Postgres Professional, системный аналитик.

Конечно, такая холиварная тема была подана не как вброс, а по-взрослому. Мне понравилось, что после исторической части, Максим разложил по 3 полочкам виды бизнес-логики в БД:

• Хранимые функции/процедуры/триггера с БЛ.

• Бизнес-инварианты в БД.

• БЛ в SQL-запросах.

То есть бизнес-логика в БД есть всегда. Даже когда нет "хранимок".

Ну и борьба со стереотипами (выбор Максима):

• РУБД не масштабируется горизонтально? - Каммон! Кроме Shardman, над которым он сам работает, Citus и Cockroach с YugobyteDB, Максим упомянул ещё и Neon, pgEdge и PgDog).

• Вендорлок? - Но с Postgres-протоколом работают такие разные СУБД как Postgres Pro, Tiger Data, GaussDB, ZomboDB, RisingWave и очереди PGMQ).

• Нет современного dev-стэка для разработчиков? - Как это? Есть Semantic Catalog, RLS, бизнес-ограничения и контроль, процедурный/view слой.

Кроме того: нынче. в эпоху ИИ работает Text2SQL, DB/SQL-агенты ходят в БД как к себе домой, напрямую - минуя слои абстракций; и вообще открывается новый архитектурный виток.

Напоследок Максим ещё и поделился графиком, на котором в 1900-м и электромобилей, и паромобилей были в 2 раза более распространены, чем экипажи с ДВС.

KVik: интегрированный key-value кеш Postgres, или как ускорить SQL в 30 раз

Postgres Pro достался целый зал, а за пару месяцев до того - целая конференция PGPro TechDay 2026. Поэтому сейчас бегло коснёмся одного доклада - про KVik. О Квике пока мало говорили. Есть довольно беглое упоминание в Postgres Pro Enterprise 18: встроенный in-memory кеш и новые горизонты отказоустойчивости. Ну и есть, конечно, солидный кусок в документации Proxima.

Большие K и V в начале названия - это Key/Value. Доклад был построен циклически: в 1-й половине перечислены и пояснены:

Проблемы внешнего кэша (обычно все тут вспоминают Redis):

• лицензирование и сопровождение;

• автоматическое восстановление;

• дополнительная точка администрирования;

• сложный код;

• инвалидация.

А во 2-й показано, как каждый из 5 пунктов закрывается при использовании KVik. В результате мы имеем:

• высокопроизводительное чтение данных - есть тесты, KVik быстрее Redis и намного (см. название доклада) быстрее PostgreSQL без специального кэша;

• поддержка RESP-протокола (Redis Serialization Protocol), команды GET, SET, DEL - поддержка протокола частичная, но полная-то вряд ли пригодится;

• автоматическая инвалидация данных в кеше при их изменении в СУБД при операциях INSERT, UPDATE, DELETE - доклад технологичный: показаны, например, наглядные схемки непростой процедуры инвалидации - там и инвалидация по событию, и инвалидация по времени;

• автоматическое изменение данных в СУБД при их изменении в кеше при операциях SET и DEL - тоже наглядные схемки.

Олег начинал с гравитации - данных. А Алексей Семихатов завершил круг докладом о гравитации "настоящей" (его доклад завершал день 1-й, а не конференцию). Алексей из тех, о ком говорят: "представлять не надо" - его видео собирают миллионы просмотров.

Как гравитация организовала почти все на свете

Но всё же представим: Алексей - завлаб, гл. научный сотрудник отделения теоретической физики Физического института им. П. Н. Лебедева РАН, ведущий передачи «Вопрос науки» на телеканале «Наука», ведёт канал «Вселенная плюс» на YouTube. «Книга года 2023» - его «Всё, что движется. Прогулки по беспокойной Вселенной».

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

Ну а мы с вами будем надеяться, что в ближайшее время ни Гравитация, ни Данные, ни кто-то другой Время не убьют. До следующей встречи!