Postgres Professional

Два доклада и один отличный повод сначала разобраться в новых возможностях Postgres Pro Enterprise 18, а потом заглянуть чуть вперед — в то, что готовит PostgreSQL 19. ✔️ Поговорили о том, что доступно уже сейчас: Марк Ривкин рассказал о новых возможностях Postgres Pro Enterprise 18 — нашей флагманской СУБД. Это важный разговор о развитии продукта, который лежит в основе сложных корпоративных инсталляций и решений Postgres Professional. ✔️ И заглянули в будущее: Павел Лузанов рассказал, что уже известно о PostgreSQL 19. До заморозки кода еще есть время, но в будущую версию уже вошло немало интересного: изменения в логической и физической репликации, работа с очисткой и анализом, улучшения производительности и не только. Все только начинается — впереди еще 50+ докладов.

Начинаем PGConf.Россия 2026! 🐘 В этом году особенно ясно, почему PostgreSQL в свои 30 лет не стал музеем: его архитектура изначально оказалась готова к будущему, которое наступило. Поэтому сегодня говорим не только о релизах и продуктах, но и о том, куда вообще движется Postgres: ✔️ От новых типов данных и специализированных индексов к новым сценариям работы, где в одной задаче сходятся операционный доступ, поиск контекста, аналитика и поиск по похожести. ✔️ Сегодня в программе — взгляд на PostgreSQL 19, решения Postgres Professional, отказоустойчивость, производительность, работа с 1С и миграция без даунтайма. Впереди 2 дня, 54 доклада и 8 мастер-классов. В центре внимания — сегодняшние возможности и перспективы Postgres на ближайшие годы. Начинаем!

Кто чаще врет — человек или искусственный интеллект? Заметим ли мы, как нас всех поработят? Обсуждаем во втором выпуске подкаста «Слон в IT-лавке» с генеральным директором Postgres Professional Иваном Панченко. В гостях: руководитель отдела машинного обучения Савелий Батурин и инженер по тестированию Виталий Ефимов. На всех мероприятиях Postgres Professional к стенду «Постгрес Помощника» (Ask Postgres) всегда самые большие очереди. Вопросов накопилось много, пришло время на них отвечать. В подкасте: ✔️ Что такое «Постгрес Помощник», на какие вопросы по СУБД он отвечает, как устроен? ✔️ В чем особенности тестирования ИИ и почему иногда сложно понять, что новая модель стала лучше отвечать на вопросы? ✔️ Нужно ли замедлить развитие ИИ, чтобы и модели, и люди не стали тупее? ✔️ Кто быстрее лишится работы из-за ИИ — администраторы баз данных или рентгенологи? ✔️ Сколько автотестеров можно заменить одной подпиской на ChatGPT? За 45 минут рассказали, как научиться отличать полезный ИИ от вредного и как изменится бизнес и разработка ПО под напором ИИ. ✔️ Смотрите на Youtube, Rutube и VK. Слушайте на Яндекс-музыке.

Приходите пробежаться! В воскресенье 22 марта проводим традиционный забег PGRun с Олегом Бартуновым. Встречаемся в 12:00 у метро «Воробьевы горы», 4 выход. Бежим по набережной до метро Деловой центр и обратно — примерно 18 километров. Можно пробежать половину. Бежим в среднем темпе — 6:00-6:30/км, чтобы подольше пообщаться. Ура весне!

Сегодня последний день регистрации на PGConf.Россия 2026 23-24 марта в Москве пройдет PGConf.Россия 2026 — крупнейшая российская конференция по PostgreSQL и решениям на ее основе, главная встреча сообщества PostgreSQL в России. Можно участвовать онлайн и офлайн. Это возможность за два дня получить срез по ключевым направлениям работы с СУБД: от новых возможностей PostgreSQL и оптимизации запросов до отказоустойчивости, масштабирования, мониторинга, миграции, безопасности, эксплуатации и ИИ. В программе: ✔️ 54 доклада от ведущих российских специалистов, экспертов сообщества и контрибьюторов PostgreSQL. ✔️ 8 мастер-классов, где возможности PostgreSQL показывают не в теории, а на практике. ✔️ Стенды с разработками на базе PostgreSQL и Postgres Pro в области отказоустойчивости, масштабируемости, безопасности, мониторинга, производительности, аналитики, миграции данных и управления БД. ✔️ Общение с сообществом и обмен опытом с теми, кто каждый день работает с PostgreSQL: разработчиками, архитекторами, DBA, тестировщиками, специалистами поддержки и инженерами эксплуатации. Расписание уже опубликовано: открывайте программу, выбирайте интересные темы и успевайте зарегистрироваться сегодня. Читайте нас в 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 были узким местом и что меняет этот патч, рассказали на Хабре.

Продлили регистрацию на PGConf.Россия 2026 до 18 марта Через неделю начнется главная конференция российского PostgreSQL-сообщества. Если планировали участвовать — решайте сейчас. 📍 Где и когда: 23-24 марта, Москва, Центр международной торговли. Можно участвовать онлайн. В программе: ✔️ 54 доклада про производительность, миграцию, безопасность, ИИ и новые возможности PostgreSQL. ✔️ 8 мастер-классов с практикой от экспертов. ✔️ Демо-стенды с решениями на базе PostgreSQL и Postgres Pro. ✔️ Нетворкинг с разработчиками, DBA и архитекторами. Регистрируйтесь сейчас, не откладывайте на потом — регистрация закрывается в среду 18 марта. Читайте нас в MAX 🤩

Гравитация организовала все на свете. Нам остается только организовывать конференции и конкурсы. Главная встреча сообщества PostgreSQL в России уже организована — PGConf.Россия 2026 пройдет 23-24 марта, а сейчас мы организуем конкурс, в котором можно выиграть билет на участие в ней. Условия конкурса: ✔️ Подписаться на канал Postgres Pro Team. ✔️ Репостнуть эту публикацию себе в истории. ✔️ Написать «Хочу на PGConf» в комментарии к этой записи. Победителя выберем 18 марта в 12:00 с помощью рандомайзера. Билет нельзя продать, поменять на деньги или передать. Участвовать можно онлайн или офлайн в Москве. Удачи и до встречи на конференции!

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 🤩

На PGConf.Россия 2026 будет несколько докладов, посвященных связке 1С и PostgreSQL. В программе — производительность типовых сценариев 1С, внутренние доработки PostgreSQL для платформы 1С:Предприятие и практические подходы к аналитике на данных 1С. Вот несколько выступлений, которые могут быть особенно интересны специалистам по 1С: 1. «Ускорение поиска в динамических списках 1С» — Антон Дорошкевич (ИнфоСофт) Поиск в динамических списках — один из самых частых сценариев работы пользователей 1С. На больших обьемах данных он может работать медленно, и эту проблему нельзя просто решить средствами СУБД. В докладе разберут причины таких ограничений и подходы, которые разрабатываются совместно с Postgres Professional, чтобы ускорить поиск в списках. 2. «Патч для PostgreSQL от 1С: доработки от 1С для работы с платформой 1С:Предприятие под большой нагрузкой» — Никита Ложкин (1С) Подробный разбор изменений PostgreSQL, которые используются платформой 1С:Предприятие. Речь пойдет о конкретных доработках: ускорении ANALYZE для широких таблиц, мультиколоночной статистике, оптимизациях для временных таблиц, расширении auto_dump и других механизмах, влияющих на производительность. 3. «Особенности построения аналитики из 1С:Предприятие в Postgres Pro AXE и Tengri Data» — Борис Бондарев (BI.Qube) Доклад о том, в каких случаях аналитическую нагрузку из 1С имеет смысл переносить во внешние системы. Спикер разберет практические сценарии извлечения данных из 1С, варианты интеграции (CDC или пакетная загрузка) и особенности работы с данными при загрузке и трансформации в Postgres Pro AXE и Tengri Data. 4. «Создание цифрового двойника 1С в экосистеме Postgres Professional на основе AXE, Tengri и BI.Qube» — мастер-класс BI.Qube Практическая сессия, где покажут, как построить обновляемую аналитическую модель данных 1С: от выгрузки справочников, регистров и документов до витрины данных и дашбордов. Участники увидят полный конвейер обработки данных и работу low-code/no-code инструментов для автоматизации аналитического слоя. 5. «Если ваш админ самурай, или история о восстановлении очень нужных данных» — Андрей Билле (Postgres Professional) Реальный кейс восстановления данных из крупной инсталляции PostgreSQL: десятки активных баз, крупнейшая — около 2 ТБ. Стандартные методы диагностики не помогали, а попытка выгрузки через pg_dump приводила к зависанию. В докладе покажут, как проблему удалось разобрать с помощью инструментов Enterprise-версии PostgreSQL и анализа кода СУБД, а также расскажут о доработке pg_dump, которую затем опубликовали для сообщества open source. Если вы работаете с 1С и PostgreSQL — в программе конференции есть темы, которые точно стоит послушать. Успейте зарегистрироваться на PGConf.Россия 2026 до 16 марта.

Миграция с 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.

Почему аналитика в компаниях часто работает медленно — даже если ресурсов достаточно? Обычно это выглядит так: Бизнес: «Аналитика готовится слишком долго». Аналитики: «Мы не можем напрямую работать с данными и ждем задач через инженеров». Инженеры: «Нельзя пускать аналитиков в центральное 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.

Как PostgreSQL может сделать больно, когда не ожидаешь Обычно проблемы с производительностью PostgreSQL ищут в медленных запросах. Но на практике все бывает сложнее: система может тормозить по причинам, которые не лежат на поверхности. В докладе с PGConf.Россия 2025 Михаил Жилин поделился реальными историями из практики перфоманс-инженеров Postgres Professional. Например: ✔️ Почему индекс может не использоваться, хотя он есть. ✔️ Как старые версии строк и MVCC могут неожиданно замедлять систему. ✔️ Почему коммит может занимать сотни миллисекунд из-за временных таблиц. ✔️ Из-за чего физическая репликация начинает отставать. Также в докладе показаны инструменты, которые помогают разбираться с такими проблемами — от perf и eBPF до профилирования и flamegraph. ✔️ Смотрите запись доклада на Youtube и Rutube, чтобы узнать, как находят и устраняют такие неожиданные проблемы в PostgreSQL. И успейте зарегистрироваться на PGConf.Россия до 16 марта, чтобы обсудить подобные кейсы с разработчиками и инженерами PostgreSQL лично.

Опубликовали расписание PGConf.Россия 2026 23-24 марта в Москве пройдет PGConf.Россия 2026 — крупнейшая российская конференция по PostgreSQL и решениям на ее основе. Это главная встреча сообщества PostgreSQL в России: два дня докладов, мастер-классов, обсуждений и общения с разработчиками и экспертами. В этом году в программе: ✔️ 51 доклад и 8 мастер-классов — про производительность, отказоустойчивость, масштабируемость, мониторинг, безопасность, миграцию БД, оптимизацию запросов и новые возможности PostgreSQL. ✔️ Выступления контрибьюторов PostgreSQL, инженеров и архитекторов ведущих ИТ-компаний. ✔️ Практические мастер-классы, где эксперты покажут работу с PostgreSQL на реальных примерах. ✔️ Демо-стенды с решениями на базе PostgreSQL и Postgres Pro — аналитика данных, ИИ, встроенная отказоустойчивость, инструменты управления БД и решения для миграции. ✔️ 1000+ специалистов по PostgreSQL — разработчики, DBA, архитекторы, инженеры поддержки и все, кто ежедневно работает с СУБД. Доклады будут идти параллельно в нескольких залах, поэтому советуем заранее посмотреть программу и выбрать выступления, которые хотите посетить. Полное расписание — на сайте. Успейте зарегистрироваться на PGConf.Россия 2026 до 16 марта и присоединиться к главной конференции российского PostgreSQL-сообщества.

Сегодня в 11:00 еще раз проведем вебинар «Postgres Pro Enterprise 18: как ускорить и обезопасить критичные системы без лишней магии». На вебинаре Марк Ривкин, руководитель отдела технического консалтинга Postgres Professional, разберет ключевые изменения в релизе Postgres Pro Enterprise 18 и покажет, как они влияют на скорость и предсказуемость эксплуатации под высокой нагрузкой. Участие бесплатное. Регистрируйтесь на корпоративную почту.

Иногда один и тот же запрос внезапно раздувается по времени: с долей миллисекунды до минут и даже часов. Причина часто не в данных и не в железе. Планировщик может недооценить кардинальность и стоимость шагов, выбрать слишком дешевый для себя план, а в реальности получить 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. Подробности читайте на Хабре.

Постгрес-хакер из Yandex Cloud Андрей Бородин приглашает на PGConf.Россия 2026. В докладе «Заметки о целостности данных» он расскажет, почему при эксплуатации большого числа баз можно столкнуться с порчей данных. В 99% случаев причина в собственных действиях: неправильно настроили fsync, запустили pg_resetwal с неверными параметрами, обновили libc слишком резко. Но иногда проблема бывает и в самом Postgres, и такие ошибки тоже нужно уметь находить и исправлять. Успейте зарегистрироваться на PGConf.Россия 2026 до 16 марта.

Кто не успел, тот получает второй шанс В четверг, 5 марта в 11:00 еще раз проведем вебинар «Postgres Pro Enterprise 18: как ускорить и обезопасить критичные системы без лишней магии». На вебинаре Марк Ривкин, руководитель отдела технического консалтинга Postgres Professional, разберет ключевые изменения в релизе Postgres Pro Enterprise 18 и покажет, как они влияют на скорость и предсказуемость эксплуатации под высокой нагрузкой. Участие бесплатное. Регистрируйтесь на корпоративную почту.

Когда служба ИБ просит логировать все, самый простой путь известен: log_statement = all. Итог тоже знакомый: диск быстро переполняется, база начинает тормозить, а в логах тонет все полезное. Мы изначально делали pg_proaudit не как замену стандартному логгеру PostgreSQL, а как дополнение: отделить аудит от технических артефактов системы и выдавать чистый поток событий для SIEM. Плюс важно не писать все подряд, а выделять конкретные зоны риска и следить именно за ними. Но первая версия уперлась в эксплуатацию: инструмент был мощный и быстрый, но его было слишком сложно настраивать. Администраторы считали, сколько правил нужно создать вручную, и часто выбирали что-то попроще. Сложная настройка всегда повышает риск ошибки: забыли одно правило и у злоумышленника появлялся шанс абсолютно незаметно проделывать грязные делишки. В 2.0 сделали ставку на обобщающие правила. Это потребовало архитектурного разворота: отказаться от хэш-таблиц в пользу оптимизированного перебора правил, чтобы поддержать классы операций, схемы, иерархию ролей и обобщения. Попутно отказались от идентификации объектов по OID в пользу имен, чтобы правила не ломались при пересоздании таблиц. В результате правил стало не сотни, а десяток, сложность управления снизилась в 50-100 раз, а в реальной нагрузке производительность не пострадала. В чем практическая польза: ✔️ Классы событий + схемы: одно правило на все DDL, модификации данных или управление ролями; если объектом указать схему, правило применится ко всем таблицам внутри нее. ✔️ Группы и иерархия ролей: правило на групповую роль срабатывает и для пользователей, которые входят в нее напрямую или косвенно. ✔️ Интеграция с SIEM: добавили поддержку CEF по запросам клиентов; теперь можно писать одновременно в CSV, CEF и syslog, а также в отдельные файлы или свой канал syslog. Из инженерных деталей: дисконнекты оказалось сложно отлавливать гарантированно, поэтому пришлось добавлять дополнительный хук прямо в ядро Postgres. С CEF пришлось повозиться из-за разных трактовок стандарта у вендоров SIEM и старых спецификаций. Подробности читайте на Хабре.