PGConf.Pоссия 2026

"Бизнес-логика в базе данных - это антипаттерн". Эта мантра передаётся разработчиками из поколения в поколение уже более 20 лет. Причины очевидны: реляционные СУБД плохо масштабируются, а реализовывать сложную бизнес-логику с их помощью неудобно и немодно. Однако у такого подхода есть и сильные стороны: мощь и выразительность языка SQL (и его процедурных расширений при необходимости), а также возможность выполнять вычисления прямо не отходя от данных. Кроме того, в последние годы правила игры начали меняться - особенно с популяризацией распределённых реляционных СУБД и AI-агентов. В докладе попробуем ответить на вопрос: действительно ли бизнес-логике не место в базе данных - или это устаревший архитектурный догмат?

Представьте, что у вас есть огромная активная база, живущая без резервной копии... И внешние силы, которые вручную удаляют старые "ненужные" файлы и аварийно останавливают сервер БД. Вроде бы вполне привычная история, но стандартные методы диагностики не работают, попытка воспользоваться pg_dump приводит к зависанию.

Неужели это точка невозврата?

• Какими инструментами мониторинга можно воспользоваться, когда ничего не помогает: gdb, crash_info...

• Плюсы работы с open source: хакнуть код pg_dump ради всеобщего блага!

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

Мы разрабатывали модуль распределённого управления настройками в крупной системе. Согласно требованиям, приложение запускалось в нескольких экземплярах (pods) с использованием одного экземпляра Postgres. При внесении изменений на любом из подов остальные должны оперативно получать уведомление. Ещё одно требование — использовать существующую инфраструктуру системы, которая не включала брокер с режимом fanout. Выход был найден — для синхронизации решили использовать... Postgres! Расскажу, что конкретно мы сделали с примерами кода бэкенда.

Новые возможности отказоустойчивого кластера Postgres Pro BiHA.