PGConf.Pоссия 2026

В архитектуре «PostgreSQL для OLTP + ClickHouse для OLAP» команда неизбежно сталкивается с фрагментацией: разные подключения в BI, разные диалекты SQL, ручные JOIN между системами через ETL и дублирование витрин. В докладе разберём практический опыт EGAR по внедрению расширения pg_clickhouse — PostgreSQL extension/FDW, который позволяет выполнять аналитические запросы на ClickHouse прямо из PostgreSQL с поддержкой pushdown (WHERE/JOIN/AGG и др.) и прозрачным подключением для BI-инструментов. Покажу архитектуру, принципы pushdown, типовые сценарии (профиль компании, отрасли, регионы, скоринг), а также ограничения и «правила безопасного применения»  (как проверять pushdown через EXPLAIN/ANALYZE, как выбирать витрины, где эффект максимален). В результате — единая точка входа в данные и ускорение дашбордов с десятков секунд до нескольких секунд на больших объёмах.

Описание: 

Описание:

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?

Сервис Едадил обрабатывает 5 миллионов чеков в день, и единственный кластер PostgreSQL на 8 ТБ перестал справляться с нагрузкой. Возможности вертикального масштабирования были исчерпаны, нужно было шардировать базу. В докладе расскажу: - Как подготовиться к шардированию: инвентаризация таблиц и SQL-запросов, выбор ключа шаржированная — и почему эта работа заняла больше времени, чем сам перевоз данных. - Поэтапная миграция без даунтайма: как мы превратили существующий кластер в первый шард и далее развезли данные на 8 шардов. - Механика перевоза данных: как работает REDISTRIBUTE в SPQR и почему реальная скорость оказалась ~1 ТБ в неделю вместо теоретических 600+ ГБ в день. - Грабли в продакшене: баг walreceiver в PostgreSQL, из-за которого лаг на репликах рос неконтролируемо, и момент, когда свободное место на реплике с 8 ТБ упало до 1%. Доклад будет полезен тем, кто стоит перед необходимостью горизонтального масштабирования PostgreSQL и хочет понять, с чем столкнётся на практике.

Расскажем про самые частые ошибки при создании бэкапов PostgreSQL. Подкрепим теорию историями из техподдержки.