PGMeetup.KZN 2025 — бесплатная встреча сообщества PostgreSQL в Казани уже 23 октября!

Остается немного времени чтобы зарегистрироваться на митап, который мы проведем в Казани. Если пропустили — вот, что вас ждет:

🔹Доклады от экспертов Postgres Professional:

✔️Павел Лузанов — PostgreSQL 18
✔️Михаил Сумской — Что происходит с шардингом в мире PostgreSQL
✔️Павел Конотопов — Расширение PostgreSQL для управления ресурсами

🔹Сертификация по PostgreSQL — можно не только узнать больше о постгресе, но и пройти профессиональное тестирование по открытой СУБД (запись — отдельная, в личном кабинете сайта postgrespro.ru)

🔹Нетворкинг, обмен опытом с сообществом и общение с командой Postgres Professional

📍 Где и когда: 23 октября в Казани, улица Петербургская, дом 52. Регистрация на месте — с 16:00, выступления начинаются в 17:00.

Участие — бесплатное, регистрация заранее на сайте обязательная.

Федеральное казначейство перевело с Oracle на Postgres Pro Shardman систему на 240 ТБ 🐘

Это крупнейшая миграция, которую когда-либо осуществляли федеральные ведомства. Про этапы перехода — в большом интервью заместителя руководителя Федерального казначейства Александра Албычева для «Российской газеты»:

✔Задача — перенести ГИС ГМП на отечественное решение. Это сложная система для уплаты пошлин, штрафов и налогов, которая обрабатывает 5000 транзакций в секунду и 20 млрд рублей в день

✔При переходе на Postgres Pro Shardman систему не останавливали. Перебои в ГИС ГМП приводят к сбою финансовой системы страны, блокировкам и задержкам платежей

✔Удалось сократить на 50 ТБ общий объем базы за счет оптимизации структуры и пересмотра накопленных данных. Обеспечена высокая отказоустойчивость и возможность горизонтального масштабирования до уровней, необходимых для работы государственных систем

➡ Сегодня 85-90% ПО Казначейства составляют отечественные решения. К 2030 году в ведомстве полностью откажутся от иностранного софта. Детали о кейсе рассказали на сайте.

🖥Postgres Pro Shardman – распределённая отечественная СУБД, способная обрабатывать данные объёмом до 2 ПБ. Хотите протестировать решение? Пишите на sales@postgrespro.ru

Читать интервью полностью

Сегодня в 11:00 стартует вебинар PGMeetup: SQL-tuning

Уже через час обсудим оптимизацию запросов в Postgres Pro. Владимир Пудовченко, технический консультант Postgres Professional, расскажет: 

✔️Как формируется план выполнения запроса и что на него влияет
✔️Какие задачи по сопровождению высоконагруженных БД решает DBA
✔️Как автоматизировать диагностику и оптимизацию в Postgres Pro Enterprise
✔️Какие инструменты Postgres Pro помогают выявлять и устранять неэффективные запросы

➡️ Подключайтесь по ссылке

Начинаем PGMeetup.KZN 2025 🐘

Встречаем гостей, занимаем места в зале и готовимся слушать доклады про СУБД. Через полчаса начинается первое выступление! Коротко о программе рассказал наш DevRel Александр Фатин.

➡️ В планах: узнать больше о 18-й версии PostgreSQL, изучить шардинг, а также управление ресурсами в постгресе. Также расскажем участниками митапа о наших проектах, проведем квиз и подарим мерч.

PostgreSQL 18 — что нового в релизе открытой СУБД?

На митапе в Казани Павел Лузанов, наш руководитель отдела образовательных программ, рассказывает про главные изменения в системе.

🖥 Хотите узнать больше о том, какие фичи пришли в постгрес с обновлением? Смотрите обзор системы, который мы ранее подготовили с Павлом.

🔥 Полный зал на докладе нашего менеджера продукта Михаила Сумского «Что происходит с шардингом в мире PostgreSQL».

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

⚡️ Павел Конотопов, руководитель отдела разработки комплексных решений, выступает с докладом «Расширение PostgreSQL для управления ресурсами» на PGMeetup.KZN 2025.

Павел рассказывает о том как мы за два дня и без ручного кода сделали расширение для контроля ресурсов через cgroups v2 — с SQL API, приоритезацией процессов и LLM в роли соразработчика.

Иван Панченко в фильме об истории российского опенсорса

Вышел трехсерийный документальный фильм Андрея и Владимира Коняевых «Свободный код», где они задались вопросом: опенсорс — утопия, двигатель прогресса или поле для жестких корпоративных игр?

Генеральный директор Postgres Professional Иван Панченко вместе другими лидерами ИТ-отрасли, программистами и юристами рассказывает, что такое опенсорс, как он меняется и куда движется:

✔️Что общего у опенсорса и советского сай-фая?
✔️Как Россия обогнала всех по применению опенсорса в серьезных государственных и бизнес-приложениях?
✔️Зачем мировое линукс-сообщество стрельнуло себе в ногу?
✔️Почему открытый код безопаснее закрытого?
✔️Как первая же разработка Олега Бартунова для PostgreSQL открыла эту СУБД миру?
✔️Почему Иван Панченко не стал воровать ПО в научных целях?

Заканчивается фильм ламповым монологом Ивана:

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

Хороших выходных и приятного просмотра!

Все серии доступны бесплатно.

PGMeetup.EKB 2025 — доклады про СУБД, ответы на вопросы и сертификация

13 ноября проведем бесплатный митап в Екатеринбурге: ответим на вопросы, обсудим ИИ-агентов, статический анализ кода, безопасность в СУБД, разберем инциденты с PostgreSQL.

Доклады от опытных специалистов:

🔹От RAG к автономности: ИИ-агент для PostgreSQL — Савелий Батурин, Postgres Professional

Как мы построили агента для работы с PostgreSQL на ReAct и MCP, используя LangChain и LangGraph. Покажем, как он сам принимает решения и формирует ответы без ручных подсказок.

🔹Статический анализ 2025: качество и безопасность кода — Глеб Асламов, PVS-Studio

Как анализаторы помогают повышать качество и безопасность кода, какие стандарты они поддерживают, и почему РБПО стало отдельным направлением развития в России.

🔹Инциденты с PostgreSQL: ошибки, сбои, инсайты — Андрей Бородин, «Яндекс»

Живые истории о том, как все пошло не по плану. Ошибки и неожиданные последствия, из которых можно вынести полезные выводы.

🔹Безопасность PostgreSQL: требования, риски, решения — Андрей Гусаков, Postgres Professional

Чего требуют регуляторы, какие их требования нельзя реализовать в ванильной версии и как выстроить надежную защиту данных в состоянии покоя.

📍 Где и когда: 13 ноября встречаемся в Екатеринбурге по адресу улица Розы Люксембург, 49. Регистрация на месте начнется в 16:00, доклады — в 17:00.

Участие — бесплатное, регистрация на сайте — обязательная.

Как замедлить Postgres в 42 000 раз и чему при этом можно научиться

Нашли, перевели и опубликовали статью про эксперимент: авторы поиграли с параметрами в postgresql.conf и уронили производительность с 7000 до 0,1 транзакций в секунду.

Это наглядный урок о том, какие настройки действительно управляют скоростью, стабильностью и эффективностью СУБД.

🖥 Как построен эксперимент

Тест TPC-C через BenchBase, 128 складов, 100 соединений, изначально — стандартная конфигурация. С этого стартового уровня Postgres выдает около 7082 TPS. Затем автор шаг за шагом крутит ручки и смотрит, как все рушится:

1️⃣ Уменьшение shared_buffers с 10 ГБ до 8 МБ снижает TPS примерно в семь раз, а до 2 МБ — почти в пятнадцать. Меньше кэша — больше обращений к диску.

2️⃣Настройки вроде autovacuum_vacuum_threshold = 0, autovacuum_naptime = 1 и крошечный maintenance_work_mem заставляют систему постоянно запускать vacuum и analyze. Сервер тратит ресурсы не на запросы, а на собственное обслуживание.

3️⃣ Частые чекпоинты, wal_sync_method = open_datasync, wal_writer_flush_after = 0 — и Postgres тонет в синхронизации и сбросах на диск. Производительность падает до сотен TPS.

4️⃣Изменение random_page_cost и cpu_index_tuple_cost на гигантские значения фактически отключает индексы, а ограничение I/O до одного воркера (io_method = worker, io_workers = 1) добивает систему. На выходе — все работает в 42 000 раз медленнее.

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

Полную версию читайте на Хабре.