title

text

PGConf.Pоссия 2026

PGConf.Россия — крупнейшая конференция по PostgreSQL в России и СНГ. Технические доклады, демонстрации решений для работы с СУБД, мастер-классы, а также нетворкинг и обмен опытом с сообществом. Ежегодно участие в PGConf.Россия принимают сотни специалистов, среди них: администраторы баз данных, архитекторы, разработчики и тестировщики, IT-менеджеры.

РЕГИСТРАЦИЯ НА МЕРОПРИЯТИЕ ЗАКОНЧЕНА.

Темы встречи

- Новости из мира PostgreSQL

- Мониторинг, отказоустойчивость и безопасность

- Облегченная миграция с Oracle, Microsoft SQL Server и других систем 

- Оптимизация запросов

- Масштабируемость, шардирование и секционирование

- Искусственный интеллект в СУБД

- Совместимость PostgreSQL с другим ПО

  • более
    0 участников
  • 0 докладчиков
  • 0
    минут общения
  • 62 доклада
  • гибридный
    формат

Доклады

Архив докладов

PGConf.Pоссия 2026
  • Дмитрий Васильев
    Дмитрий Васильев Ozon Эксперт по разработке информационных систем
    Григорий Смолкин
    Григорий Смолкин Ozon Инженер

    Что происходит, когда в вашей инфраструктуре появляются десятки тысяч PostgreSQL-кластеров? Patroni — зрелый и надёжный инструмент для автоматизации высокой доступности, и мы в OZON убедились в этом на практике. Но даже с отличным инструментом возникают задачи, которые хочется решить ещё удобнее. В докладе Григорий Смолкин и я поделимся рецептами, которые мы выработали за годы эксплуатации: как сделать работу с Patroni не просто надёжной, а по-настоящему приятной. Вы узнаете:

    • Как мы организовали процедуру bootstrap, чтобы развёртывание новых кластеров стало предсказуемым и быстрым

    • Какие подходы к управлению ролями узлов упрощают жизнь при распределённой топологии

    • Как безболезненно выводить узлы из эксплуатации в автоматическом режиме не ломая сервис

    • Какие метрики жизненного цикла помогают предотвращать инциденты до их возникновения

    Доклад будет полезен всем, кто эксплуатирует PostgreSQL с Patroni и хочет вывести свои операционные практики на новый уровень комфорта.

  • Александр Буров
    Александр Буров ООО «Компания ИНВЕРСИЯ» Руководитель отдела «Трансграничные переводы»
    Илья Андреев
    Илья Андреев Компания ИНВЕРСИЯ Руководитель отдела «Сопровождение Ядра АБС»

    В конце 25-го года нами была развёрнута БД Postgres Pro Enterprise 17.5 на полигоне ЦБ. В ходе функционального и нагрузочного тестирования АБС в рамках импортонезависимого стека СУБД+клиент+железо СУБД показала высокую производительность с большим запасом, а нами был получен колоссальный опыт, которым мы хотим с Вами поделиться. Мы расскажем, как решили проблему «счетчиков», при чем тут отложенные обороты и как бороться с «пухнущими» индексами.

  • Yandong Yao
    Yandong Yao

    YMatrix is a distributed, multi-model database built on PostgreSQL. Domino is its native in-database stream processing engine, enabling true unified batch and stream processing. This talk explores the design concepts, technology selection, and implementation of in-database stream processing in YMatrix, aiming to address the complexity, resource overhead, and consistency challenges of traditional external streaming architectures. Background and Motivation In conventional data architectures, data is extracted from OLTP systems and processed either through T+1 batch pipelines or external stream processing engines (such as Flink) before being loaded into data marts. This approach suffers from limited real-time capabilities, high system complexity, data redundancy, and potential consistency risks. In-database stream processing offers a more efficient alternative by simplifying system architecture, reducing resource consumption, strengthening data lineage, and improving flexibility. Core Design GoalsThe system is designed to support incremental processing (distinct from materialized views), near real-time latency (sub-second or configurable), multi-stage stream concatenation, minimal impact on OLTP workloads (better than trigger-based solutions), eventual consistency, and high-throughput processing. Meanwhile, it provides full SQL-level semantics, avoiding the need for user-defined code. Technical Implementation - SQL Syntax DesignThe SQL grammar is extended with CREATE STREAM ... AS SELECT ... STREAMING to define stream objects that subscribe to incremental changes from upstream tables. The semantics resemble materialized views but support continuous incremental updates. - Incremental Data CaptureLogical Decoding is used to create replication slots for capturing WAL changes. Combined with initial historical snapshots to initialize stream tables, background workers continuously execute incremental query plans to synchronize streaming tables. - Progress ManagementStream progress (restart_lsn / confirm_lsn) is maintained in shared memory and atomically updated on transaction commit. Integration with XLog and checkpoint mechanisms ensures reliable crash recovery. - Plugin FrameworkThe framework supports three primary SQL patterns: single-stream join with dimension tables (domino_one), single-stream aggregation (domino_agg), and dual-stream Inner Join (domino_join). Each plugin matches SQL query patterns and generates corresponding incremental execution plans. - Update HandlingLogical Decoding outputs DELETE/INSERT markers, and primary-key conflict handling (INSERT ... ON CONFLICT) enables incremental propagation of upstream updates and deletes. For aggregation, inverse transition functions (aggmtransfn / aggminvtransfn) are introduced to support retraction. Dual-stream join scenarios further support arbitrary update/delete operations on both input streams. BenefitsCompared with external streaming engines, this approach significantly simplifies system architecture, reduces resource costs (cutting down serialization and network transmission overhead), strengthens data consistency guarantees, and lowers the user adoption barrier through pure SQL semantics.

  • Олег Гурьев
    Олег Гурьев Postgres Professional Разработчик ПО

    Описание: 

    Описание:

    1. Как PostgreSQL хранит данные на диске? 

    2. Что такое форки, бэкенды и процессы в PostgreSQL?

    3. Что такое буферный кэш и почему страницы там пачкаются?

    4. Какие бэкенды могут записывать страницы на диск?

    5. Как и где работает CFS?

    6. Почему в CFS нужно убирать мусор и какие бэкенды этим занимаются?

    7. Что такое физические и логические резервные копии?

    8. Зачем еще нужно хранить архив WAL?

    9. Что происходит с PostgreSQL и CFS, когда вы начинаете делать резервную копию?

    10. Почему возникали проблемы при снятии бэкапов с CFS?

    11. Как бы эти проблемы решили?

    12. Что еще оптимизировано в связке pg_probackup + CFS?

    13. Можно ли делать резервные копии другими инструментами?

    14. Что такое TDE и можно ли использовать его совместно с CFS?

Все доклады

Партнёры

PGConf.Pоссия 2026

Информационные партнёры

Партнёр