Зарегистрируйтесь на PGConf.Russia 2026 со скидкой 15% — до 28 февраля

После 28 февраля вырастет стоимость участия в крупнейшей российской конференции по PostgreSQL и решениям на ее основе. Сейчас билет можно купить со скидкой 15%.

📍 Конференция пройдет 23-24 марта в Центре международной торговли в Москве. Можно участвовать онлайн или офлайн.

Что входит в билеты:

✔️ Онлайн: трансляция конференции, записи докладов и презентации.

✔️ Офлайн: выставка и мастер-классы, велкомпак, 3 кофе-брейка, горячий обед в оба дня конференции, вечернее мероприятие с фуршетом и музыкальной группой в первый день 23 марта.

В программе:

➡️ Мастер-классы: эксперты по PostgreSQL покажут на практике, какие возможности доступны в СУБД.

➡️ Демо-стенды: разработки в области отказоустойчивости, масштабируемости, безопасности, мониторинга и производительности.

➡️ 40+ докладов от специалистов ИТ-компаний и экспертов сообщества.

➡️ Темы: производительность, отказоустойчивость и масштабируемость, мониторинг, новости PostgreSQL, миграция БД, оптимизация запросов, безопасность, эксплуатация, ИИ.

Регистрируйтесь на PGConf.Russia 2026 до 28 февраля со скидкой 15% — обсудим практику и новые фичи СУБД, поговорим о PostgreSQL и не только.

Тестовый контур без утечек: 2 доклада с PGConf.Russia 2025

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

Публикуем два видео с PGConf.Russia 2025, которые закрывают задачу с двух сторон.

В докладе «Портим данные с удовольствием» Максим Грамин, системный аналитик Postgres Professional, разбирает, как маскировать, заменять и генерировать данные, и какие проблемы искусственных данных решаются средствами PostgreSQL и расширениями.

✔️ Смотрите доклад Максима на Youtube и Rutube.

Во втором докладе «Greenmask — опенсорсный инструмент для создания тестового окружения и не только» Вадим Войтенко, основатель Greenmask, показывает, как применять инструмент для подготовки тестового контура и объясняет архитектуру, database subset, трансформации и интеграцию с драйвером PostgreSQL.

✔️ Смотрите доклад Вадима на Youtube и Rutube.

На PGConf.Russia 2026 будет еще больше прикладных разборов про PostgreSQL и практик эксплуатации. Регистрируйтесь до 28 февраля со скидкой 15%.

Когда служба ИБ просит логировать все, самый простой путь известен: log_statement = all. Итог тоже знакомый: диск быстро переполняется, база начинает тормозить, а в логах тонет все полезное.

Мы изначально делали pg_proaudit не как замену стандартному логгеру PostgreSQL, а как дополнение: отделить аудит от технических артефактов системы и выдавать чистый поток событий для SIEM. Плюс важно не писать все подряд, а выделять конкретные зоны риска и следить именно за ними.

Но первая версия уперлась в эксплуатацию: инструмент был мощный и быстрый, но его было слишком сложно настраивать. Администраторы считали, сколько правил нужно создать вручную, и часто выбирали что-то попроще.

Сложная настройка всегда повышает риск ошибки: забыли одно правило и у злоумышленника появлялся шанс абсолютно незаметно проделывать грязные делишки.

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

Попутно отказались от идентификации объектов по OID в пользу имен, чтобы правила не ломались при пересоздании таблиц. В результате правил стало не сотни, а десяток, сложность управления снизилась в 50-100 раз, а в реальной нагрузке производительность не пострадала.

В чем практическая польза:

✔️ Классы событий + схемы: одно правило на все DDL, модификации данных или управление ролями; если объектом указать схему, правило применится ко всем таблицам внутри нее.

✔️ Группы и иерархия ролей: правило на групповую роль срабатывает и для пользователей, которые входят в нее напрямую или косвенно.

✔️ Интеграция с SIEM: добавили поддержку CEF по запросам клиентов; теперь можно писать одновременно в CSV, CEF и syslog, а также в отдельные файлы или свой канал syslog.

Из инженерных деталей: дисконнекты оказалось сложно отлавливать гарантированно, поэтому пришлось добавлять дополнительный хук прямо в ядро Postgres. С CEF пришлось повозиться из-за разных трактовок стандарта у вендоров SIEM и старых спецификаций.

Подробности читайте на Хабре.

Иногда один и тот же запрос внезапно раздувается по времени: с долей миллисекунды до минут и даже часов. Причина часто не в данных и не в железе.

Планировщик может недооценить кардинальность и стоимость шагов, выбрать слишком дешевый для себя план, а в реальности получить Nested Loop там, где выгоднее Hash Join, или Seq Scan вместо Index Scan.

Бывает и так, что дерево запроса устроено неудачно: нужные условия спрятаны, и часть эффективных алгоритмов просто не рассматривается.

Эти случаи закрывает расширение pgpro_planner. Оно переписывает неудобные для оптимизатора куски дерева запроса в более дружелюбный вид еще до того, как основной планировщик выберет план.

Ниже — три примера небольших оптимизаций с большим эффектом.

✔️ IN (VALUES ...) → = ANY(array)

В одном запросе из мира 1С фильтры были оформлены как IN (VALUES ...) для numeric и bytea. До обновления статистики он работал быстрее 1 мс, после — около 7,5 с.

В плане львиная доля времени ушла в Nested Loop Semi Join и материализацию маленьких таблиц из VALUES. Индекс почти не помогал, потому что сравнение было внутри join-фильтра, а не в Index Cond.

Решение: собрать константы VALUES в массив и переписать условие как = ANY(array). Тогда индекс попадает в Index Cond, из плана исчезают лишние Semi Join и временные таблицы, а время падает с секунд до долей миллисекунды.

Эту функциональность в итоге закоммитили в PostgreSQL 18.

✔️ Простейшая арифметика, которая ломает индекс

Выражения x + 0, x * 1, x / 1, x - 0 равны x, но планировщик не обязан это распознавать. Поэтому условие x + 0 > 900 может дать Seq Scan, хотя x > 900 позволяет построить Index Only Scan. Шаг упрощения делает предикат индексируемым еще до планирования.

✔️ Memoize для коррелированных подзапросов

В бенчмарке один и тот же подзапрос выполнялся 14 835 720 раз и давал Execution Time 496 690 мс. Узел Memoize кеширует результат по ключу параметра и возвращает его из кеша при повторе. Итог — 115 528 мс, то есть ускорение в четыре с лишним раза.

Подключается это все как обычное расширение оптимизатора: через LOAD pgpro_planner в сессии или через shared_preload_libraries с перезагрузкой.

Затем включают pgpro_planner.enable = true и при необходимости управляют отдельными функциями: преобразованием VALUES, упрощением тривиальных выражений и Memoize.

Подробности читайте на Хабре.

Опубликовали расписание PGConf.Россия 2026

23-24 марта в Москве пройдет PGConf.Россия 2026 — крупнейшая российская конференция по PostgreSQL и решениям на ее основе. Это главная встреча сообщества PostgreSQL в России: два дня докладов, мастер-классов, обсуждений и общения с разработчиками и экспертами.

В этом году в программе:

✔️ 51 доклад и 8 мастер-классов — про производительность, отказоустойчивость, масштабируемость, мониторинг, безопасность, миграцию БД, оптимизацию запросов и новые возможности PostgreSQL.

✔️ Выступления контрибьюторов PostgreSQL, инженеров и архитекторов ведущих ИТ-компаний.

✔️ Практические мастер-классы, где эксперты покажут работу с PostgreSQL на реальных примерах.

✔️ Демо-стенды с решениями на базе PostgreSQL и Postgres Pro — аналитика данных, ИИ, встроенная отказоустойчивость, инструменты управления БД и решения для миграции.

✔️ 1000+ специалистов по PostgreSQL — разработчики, DBA, архитекторы, инженеры поддержки и все, кто ежедневно работает с СУБД.

Доклады будут идти параллельно в нескольких залах, поэтому советуем заранее посмотреть программу и выбрать выступления, которые хотите посетить.

Полное расписание — на сайте.

Успейте зарегистрироваться на PGConf.Россия 2026 до 16 марта и присоединиться к главной конференции российского PostgreSQL-сообщества.

Как PostgreSQL может сделать больно, когда не ожидаешь

Обычно проблемы с производительностью PostgreSQL ищут в медленных запросах. Но на практике все бывает сложнее: система может тормозить по причинам, которые не лежат на поверхности.

В докладе с PGConf.Россия 2025 Михаил Жилин поделился реальными историями из практики перфоманс-инженеров Postgres Professional. Например:

✔️ Почему индекс может не использоваться, хотя он есть.

✔️ Как старые версии строк и MVCC могут неожиданно замедлять систему.

✔️ Почему коммит может занимать сотни миллисекунд из-за временных таблиц.

✔️ Из-за чего физическая репликация начинает отставать.

Также в докладе показаны инструменты, которые помогают разбираться с такими проблемами — от perf и eBPF до профилирования и flamegraph.

✔️ Смотрите запись доклада на Youtube и Rutube, чтобы узнать, как находят и устраняют такие неожиданные проблемы в PostgreSQL.

И успейте зарегистрироваться на PGConf.Россия до 16 марта, чтобы обсудить подобные кейсы с разработчиками и инженерами PostgreSQL лично.

Почему аналитика в компаниях часто работает медленно — даже если ресурсов достаточно?

Обычно это выглядит так:

Бизнес: «Аналитика готовится слишком долго».

Аналитики: «Мы не можем напрямую работать с данными и ждем задач через инженеров».

Инженеры: «Нельзя пускать аналитиков в центральное DWH — один неудачный запрос может положить систему».

Такая ситуация встречается почти везде: в классических DWH Greenplum и Vertica, в современных системах вроде StarRocks и даже в lakehouse-инсталляциях на базе Spark. Причина — в архитектуре.

Где возникает проблема

Во многих аналитических СУБД есть общий компонент, через который проходит обработка запросов.

Из-за этого появляются узкие места. Например:

✔️ В Greenplum любой запрос проходит через ноду-координатор.

✔️ В Vertica нагрузка ложится на глобальный каталог.

✔️ В Spark и StarRocks один некорректный запрос может занять все вычислительные слоты.

В результате тяжелый запрос начинает тормозить работу всей системы. Ресурсные группы, квоты и другие механизмы лишь ограничивают ущерб, но не устраняют саму причину — конкуренцию за ресурсы.

Выход: изолировать вычисления

Если дать аналитикам полную свободу, идеальная система должна работать иначе.

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

Именно такую архитектуру показал Snowflake с моделью shared data — independent compute.

Сессионные вычислители

Для каждой пользовательской сессии запускается отдельный легковесный SQL-вычислитель. Он стартует за доли секунды, подтягивает только нужные данные из хранилища и выполняет запрос, не мешая соседним сессиям.

Фактически каждый аналитик получает свой изолированный вычислитель.

Что это дает

При такой архитектуре пользователи перестают конкурировать за ресурсы:

✔️ Запросы аналитиков не мешают друг другу.

✔️ Тяжелые задачи не блокируют отчеты и ETL.

✔️ Систему можно масштабировать, просто добавляя вычислительные узлы.

Как это работает на практике

Такой подход реализован в аналитической системе Tengri, которую развивает Postgres Professional. Она использует архитектуру сессионных вычислителей и независимых SQL-воркеров.

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

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

Читайте подробности на Хабре.

Убедиться в приведенных цифрах можно в документации.

Если любите смотреть, а не читать, сохраняйте плейлист на Youtube.

Миграция с Oracle: реальные кейсы с PGConf.Россия 2025

Собрали три выступления с прошлогодней конференции о переносе систем с Oracle на PostgreSQL и Postgres Pro — от государственных информационных систем до банковской инфраструктуры и многотерабайтных баз данных.

1. Практика миграции региональных систем управления общественными финансами с Oracle/Firebird на Postgres
Оксана Щеглова, БФТ

Опыт переноса региональных систем управления общественными финансами. В докладе — этапы миграции, разработка собственного инструмента для переноса данных и типичные проблемы: несовместимые типы данных, различия в обработке строк и NULL, а также необходимость переработки части бизнес-логики при переходе на PostgreSQL.

✔️ Смотреть на Youtube и Rutube.

2. Миграция с Oracle: большая нагрузка и много шардов
Алексей Светличный, Т-Банк

Кейс миграции критичной банковской системы авторизации. Вместо одной большой базы Oracle была построена распределенная архитектура из десятков PostgreSQL-шардов. В докладе — архитектура решения и практические проблемы после перехода: оптимизация запросов и индексов, влияние статистики на планировщик и особенности работы с партициями.

✔️ Смотреть на Youtube и Rutube.

3. Миграция высоконагруженной 40-ТБ базы данных из Oracle в Postgres
Ирина Токарева и Сергей Кузнецов, ОТР

Разбор проекта переноса промышленной базы данных объемом около 40 ТБ. Спикеры рассказывают о стратегии поэтапной миграции с использованием ora2pg, синхронизации изменений между этапами и проблемах, которые проявились уже под промышленной нагрузкой.

✔️ Смотреть на Youtube и Rutube.

Если вам актуальна тема миграции — успейте зарегистрироваться на PGConf.Россия 2026 до 16 марта. Как и каждый год, на конференции будет много практических докладов о миграции, архитектуре и эксплуатации больших баз данных.

Следите за новостями Postgres Professional в MAX.

PostgreSQL + 1C = 💛

На PGConf.Россия 2026 поговорим об этой любви:

1. «Ускорение поиска в динамических списках 1С» — Антон Дорошкевич (ИнфоСофт)

Почему поиск в динамических списках 1С на больших обьемах данных замедляется и какие подходы разрабатываются совместно с Postgres Professional, чтобы ускорить этот типичный пользовательский сценарий.

2. «Патч для PostgreSQL от 1С: доработки от 1С для работы с платформой 1С:Предприятие под большой нагрузкой» — Никита Ложкин (1С)

Разбор ключевых доработок PostgreSQL для платформы 1С:Предприятие — включая ускорение ANALYZE для широких таблиц, мультиколоночную статистику и оптимизации работы с временными таблицами.

3. «Если ваш админ самурай, или история о восстановлении очень нужных данных» — Андрей Билле (Postgres Professional)

Кейс спасения огромной 1С-базы: как возможности Postgres Pro Enterprise воскрешают даже мертвые базы.

4. «Особенности построения аналитики из 1С:Предприятие в Postgres Pro AXE и Tengri Data» — Борис Бондарев (BI.Qube)

О том, когда аналитику из 1С имеет смысл выносить во внешние системы и как организовать извлечение, загрузку и трансформацию данных в Postgres Pro AXE и Tengri Data.

Также коллеги из BI.Qube проведут мастер-класс «Создание цифрового двойника 1С в экосистеме Postgres Professional на основе AXE, Tengri и BI.Qube».

Если вы работаете с 1С и PostgreSQL — в программе конференции есть темы, которые точно стоит послушать. Успейте зарегистрироваться на PGConf.Россия 2026 до 16 марта.

Читайте нас в MAX 🤩

Гравитация организовала все на свете. Нам остается только организовывать конференции и конкурсы.

Главная встреча сообщества PostgreSQL в России уже организована — PGConf.Россия 2026 пройдет 23-24 марта, а сейчас мы организуем конкурс, в котором можно выиграть билет на участие в ней.

Условия конкурса:

✔️ Подписаться на канал Postgres Pro Team.

✔️ Репостнуть эту публикацию себе в истории.

✔️ Написать «Хочу на PGConf» в комментарии к этой записи.

Победителя выберем 18 марта в 12:00 с помощью рандомайзера.

Билет нельзя продать, поменять на деньги или передать. Участвовать можно онлайн или офлайн в Москве.

Удачи и до встречи на конференции!

Продлили регистрацию на PGConf.Россия 2026 до 18 марта

Через неделю начнется главная конференция российского PostgreSQL-сообщества. Если планировали участвовать — решайте сейчас.

📍 Где и когда: 23-24 марта, Москва, Центр международной торговли. Можно участвовать онлайн.

В программе:

✔️ 54 доклада про производительность, миграцию, безопасность, ИИ и новые возможности PostgreSQL.

✔️ 8 мастер-классов с практикой от экспертов.

✔️ Демо-стенды с решениями на базе PostgreSQL и Postgres Pro.

✔️ Нетворкинг с разработчиками, DBA и архитекторами.

Регистрируйтесь сейчас, не откладывайте на потом — регистрация закрывается в среду 18 марта.

Читайте нас в MAX 🤩

В PostgreSQL стало на одно старое ограничение меньше: MultiXactOffset перевели на 64 бита. Это касается не редкой внутренней детали, а механизма мультитранзакций, который используется при блокировках строк, SELECT ... FOR SHARE/UPDATE и проверке внешних ключей.

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

Проблема была в том, что offsets оставался 32-битным. При этом мультитранзакции неизменяемы: если к блокировке добавляется еще одна транзакция, создается новая структура. Из-за этого при повторных блокировках одной и той же строки офсеты могут расти квадратично — 1, 3, 6, 10. На нагруженных системах это создавало реальный риск переполнения, а заметить его заранее было непросто.

Теперь PostgreSQL использует 8-байтные offsets, и риск такого переполнения минимален. Компромисс тоже есть: сегменты offsets выросли вдвое, а при обновлении нужна дополнительная конвертация через pg_upgrade. Но взамен PostgreSQL получает больше запаса до жестких лимитов и более предсказуемое администрирование.

Подробно о том, как устроены мультитранзакции, почему именно offsets были узким местом и что меняет этот патч, рассказали на Хабре.

Читайте нас в MAX 🤩