Провести честный тест на 30 000 ВРМ, сжечь 400 тысяч процессорных ядер-часов и доказать, что отечественная связка из RED OS, 1С и Postgres Pro Enterprise способна стабильно держать промышленную нагрузку в 1 Тб — выполнено. Рассказываем историю одного большого нагрузочного тестирования длиною в три месяца
Каждый раз, когда пользователь открывает страницу каталога или дашборд со статистикой, база данных заново считает одно и то же. Запрос к 800 тысячам строк ради одного числа — снова и снова. Расширение pgpro_result_cache в Postgres Pro Enterprise решает эту проблему на уровне СУБД: результат тяжёлого запроса сохраняется в разделяемой памяти и при повторном обращении возвращается за миллисекунду — без сканирования, без нагрузки на процессор, прозрачно для приложения. В этой статье разберём, как это работает, когда кэш действительно полезен и на что нужно обратить внимание при настройке.
Бурное развитие нейросетевых способов разработки подсказывает вопрос:
В мире имеется огромный склад чемоданов без ручек. Это старьё, эта рухлядь, пусть они и милые сердцу и в них вложены труд и талант, их называют легаси. Это и софт (чаще), и железо. Руки программистов-старьёвщиков не доходят до них, до этих легасей, и уже вряд ли дойдут. Но вдруг дотянутся хищные лапищи нейросетей?
Почему бы нет: дело почти рутинное, архитектуры изобретать не надо. Просто переписать с минимумом ошибок. Нет, не просто. Проблемы есть.
Проблема тренировочных данных для легаси-языков:
современные LLM обучены преимущественно на публичных репозиториях (GitHub и др);
легаси-код (COBOL, RPG, SAS, PowerBuilder) часто закрыт, проприетарен или представляет собой «игрушечные примеры», не отражающие реальную бизнес-логику;
в результате: ИИ «знает синтаксис», но не понимает контекст корпоративных систем. Получается разорванный цикл обратной связи.
Конференция прошла 23-24 марта в московском Центре Международной Торговли, а на днях для участников выложили видео, презентации и фото. В этом году конференцию посетило примерно 1300 очно и 800 заочно. По сравнению с прошлой конференцией она немного подросла: на PGConf.Russia 2025 было 1120 очных, в сумме около 2 тыс. человек. Конференция претерпела лёгкий ребрендинг: PGConf.Russia => PGConf.Россия (переход плавный: PGConf.СПб 2025, а не SPb). Доклады на этот раз проходили в 4 залах (на прошлой - в 3): главный - сдвоенный и 3 зала поменьше. Один из них был отдан целиком Postgres Pro. Ещё в 2 залах проходили мастер-классы.
Команда экспертов Postgres Professional — Павел Лузанов, Егор Рогов и Игорь Лёвшин — представила обновлённое 12-е издание своего бестселлера «Postgres. Первое знакомство». Главная новость: книга актуализирована под возможности новейшей 18-й версии PostgreSQL.
Это небольшое, но ёмкое руководство призвано максимально быстро и комфортно погрузить читателя в работу с самой продвинутой СУБД с открытым кодом.
Медленный запрос — это не приговор, это задача со своим решением. Но найти его невозможно, пока планировщик PostgreSQL остаётся для вас чёрным ящиком. Книга Павла Толмачёва «PostgreSQL 16. Оптимизация запросов» даёт то, чего не хватает большинству разработчиков и администраторов: системное понимание того, как планировщик принимает решения, — и практические инструменты, чтобы направить его в нужную сторону.
Apache AGE добавляет графы и Cypher в PostgreSQL. Мы написали бенчмарк, прогнали три типа нагрузки и обнаружили, что поиск кратчайшего пути выдаёт 7 TPS, а вставка вершин деградирует из-за SeqScan в функции проверки существования. Один патч — и TPS вырос в 15 раз. Рассказываем, как до этого докопались.
Если вы администрируете Postgres Pro Enterprise и ваша инфраструктура охватывает несколько дата-центров, вы наверняка сталкивались с одной и той же проблемой: репликация начинает «есть» межцодовый канал и нагружать основной сервер. В новой версии BiHA появилось решение — каскадная репликация. Рассказываем, как она работает и когда стоит использовать её.
На разных континентах и субконтинентах
В расписании конференции PGConf.Russia, к которой мы ещё, конечно, вернёмся в разделе Конференции, моё внимание привлёк вот такой доклад:
YMatrix Domino: Design Considerations, Trade-offs, and Implementation of In-Database Stream Processing - видимо, игрек впереди названия как раз в честь Яо Яндуна (Yandong Yao), гендира и сооснователя компании Ymatrix (также известной как Beijing Siwei Zongheng Data Technology Co., Ltd. или «Сывэй Цзунхэн»). Не думаю, что многим читателям этих обзоров она известна хотя бы по одному из этих названий.
Он экс-руководитель пекинского R&D-центра Greenplum.
Оказывается, на хабре есть статья о YMatrix:
Мы продолжаем серию интервью с разработчиками Postgres Professional, которые получили медали за вклад в ванильный PostgreSQL. Почему полезен даже не принятый сообществом патч и при чём здесь везение, сегодня расскажет Александр Пыхалов.
Ещё в 1987 году Майкл Стоунбрейкер в основополагающем документе «The Design of POSTGRES» написал, что транзакции должны быть 64-битными. Прошло почти 40 лет — и Postgres до сих пор живёт в мире 32-битных счётчиков. Но в декабре 2025 года в кодовую базу тихо вошёл мой коммит, который стал первым реальным шагом к тому, о чём думал Стоунбрейкер. Расскажу, что именно изменилось и почему это важнее, чем кажется.
Когда речь заходит об оптимизации базы данных, разработчики обычно перечисляют привычный набор приёмов: слегка переписать запрос, накинуть индекс на колонку, денормализовать, сделать analyze, vacuum, cluster, и так по кругу. Классические техники, конечно, работают, но иногда креативный подход даёт гораздо больше.
В этой статье Haki Benita показывает нетипичные техники оптимизации в PostgreSQL.
Вечный конфликт: аналитики требуют свободы маневра, а DBA закрывают доступ к базе, опасаясь одного «убийственного» запроса, который положит весь кластер. В Postgres Professional мы разработали Tengri — систему, где каждый пользователь получает изолированные вычислительные ресурсы. Рассказываю, как архитектура индивидуальных вычислителей позволяет избежать конкуренции за ресурсы и почему после такого опыта возвращаться к общим очередям запросов уже не хочется.
PostgreSQL 19 news:
PostgreSQL 19: Часть 1 или Коммитфест 2025-07, Часть 2, Часть 3 и Часть 4
Это традиционные обзоры Павла Лузанова, начальника отдела образования Postgres Professional. Начнём с конца, вот некоторые:
Секционирование: слияние и разделение секций:
Первая и неудачная попытка реализации команд для слияния и разделения секций секционированной таблицы была в 17-й версии: незадолго до выпуска патчи были отменены. Сейчас вторая попытка, хоть и с серьезными ограничениями.
Клиент, с проблемы которого всё началось, решил её сам — сменил фреймворк и даже не стал дожидаться патча. Но Алёна Рыбакина всё равно продолжила работу — ещё год. Теперь её OR-ANY Transformation — часть PostgreSQL, а сама она — обладательница медали сообщества. Интервью о том, как случайный клиентский баг превращается в вклад в мировой open source.
Проводить нагрузочное тестирование PostgreSQL — полдела. Главная сложность начинается, когда нужно проанализировать сотни результатов и понять, где реальная просадка производительности, а где статистический шум. Младшие специалисты Postgres Professional Евгений Бузюркин, Дарья Барсукова и Рустам Хамидуллин разработали инструмент, который автоматически определяет тип распределения данных, детектирует мультимодальность и подбирает оптимальные параметры для каждого набора результатов бенчмарков.
Рынок IT перегрет, но не дефицитом кадров, а спамом из автооткликов. Когда на позицию Senior QA приходит 450 заявок, времени на вдумчивое чтение нет. HRD Postgres Professional Ксения Замуховская честно рассказывает, как выглядит процесс отбора изнутри: почему джоб-хопперов боятся больше, чем возрастных кандидатов, и зачем указывать закрытие проекта в причинах увольнения, чтобы вас не посчитали «летуном».
Асинхронный ввод-вывод, ML-оптимизация планов запросов и встроенный пулинг соединений — ключевые особенности новой Postgres Pro Enterprise 18. Релиз объединил возможности ванильного ядра PostgreSQL 18 и Enterprise-инструменты для работы с большими данными. Расскажем про технические детали, новые стратегии сканирования индексов и механизмы масштабирования записи.
