Команда экспертов Postgres Professional — Павел Лузанов, Егор Рогов и Игорь Лёвшин — представила обновлённое 12-е издание своего бестселлера «Postgres. Первое знакомство». Главная новость: книга актуализирована под возможности новейшей 18-й версии PostgreSQL.
Это небольшое, но ёмкое руководство призвано максимально быстро и комфортно погрузить читателя в работу с самой продвинутой СУБД с открытым кодом.
Настоящая статья подготовлена с использованием технологий искусственного интеллекта.
В частности:
— экспериментальные данные обработаны и проанализированы нейросетью;
— иллюстративный материал, сопутствующие слоганы, а также предисловие и послесловие сгенерированы нейросетью;
— макет статьи редактировался и корректировался нейросетью.
Лицам, придерживающимся позиции «ИИ-веганства» (испытывающим устойчивый страх, неприязнь или психологический дискомфорт по отношению к нейросетевым системам), настоятельно не рекомендуется ознакомление с содержанием данной публикации, равно как и участие в её обсуждении, во избежание возможного нанесения вреда психологическому благополучию.
Логическая репликация в Postgres редко ломает прод внезапно — чаще она долго и методично копит проблему, пока replication slot удерживает всё больше WAL, потребитель отстаёт, а свободное место на диске начинает таять. В этой статье разбирается именно такая зона риска: как устроена работа replication slots, почему одних базовых настроек здесь недостаточно и какие практики реально помогают держать под контролем WAL, публикации, heartbeats, failover и мониторинг. Материал особенно полезен тем, кто работает с CDC, Debezium и production-инстансами Postgres, где цена ошибки измеряется уже не теорией, а стабильностью системы.
Привет, Хабр!
В течение последнего года я занимался разработкой аналитической панели для продавцов на маркетплейсах Wildberries и Ozon, а в перспективе планируется интеграция с Яндекс.Маркет. Я хотел бы поделиться своим опытом и представить систему WBOZYA-dash, которая предназначена для анализа продаж через эти маркетплейсы. До конца весны 2026 выпущу, думаю, с десяток статей на эту тему, а пока сделаю общий обзор своей системы.
Вторая часть серии по PostgreSQL из моих внутренних докладов. В этот раз — индексы: откуда берётся cost в EXPLAIN и почему это «попугаи», а не миллисекунды. Почему PostgreSQL игнорирует ваш индекс при высоком покрытии таблицы. Как физическое расположение данных на диске влияет на скорость даже при наличии индекса. Плюс GiST для нечёткого поиска с триграммами, GIN для полнотекстового поиска и EXCLUDE constraints для задач типа бронирования. Всё на примере таблицы с 4 миллионами строк.
На этапе тестирования я отобрал 6 городов (Москва, Санкт-Петербург, Новосибирск, Екатеринбург, Казань, Красноярск) и двух крупнейших провайдеров России - Ростелеком и Дом.ру. В планах масштабирование на большее количество городов и операторов.
Для парсинга тарифов у провайдеров применял связку Python + Selenium + BeautifulSoup, через хранимую процедуру складывал полученные данные в базу PostgreSQL.
Будучи поклонником идеи Айзека Азимова о коллаборации C/Si форм жизни, я провёл эксперимент и сгенерировал данный текст автоматически, AI агентом, по контексту, сформированному в процессе разработки новой фичи оптимизатора Postgres и расследования проблемного corner case, который время от времени завершался с runtime-ошибкой. Это первый опыт подобной совместной работы и проба пера, поэтому возможны шероховатости. Однако сама проблема и вариант решения для Postgres валидированы вручную. Любая, даже самая жёсткая критика, приветствуется.
Статья родилась в ходе наблюдения за одной из систем на Postgres, что у нас на поддержке. Результаты наблюдения несколько удивили, поэтому делюсь, ибо причинно-следственные связи далеко не очевидны.
Триггером к изучению, можно сказать, даже к расследованию, послужило событие, когда однажды утром сервер PG завалился, потому что процессы postgres заняли всю память.
В статье дан обзор одного из докладов конференции PgConf, которая прошла 23-24 марта 2026 года, Андрея Билле, главного инженера компании Postgres Professional. Название доклада: «Если ваш админ самурай или история о восстановлении очень нужных данных».
Мониторинг PostgreSQL сломан: 150 метрик в pg_stat_*, и ни одна не отвечает на вопрос «база здорова?». В статье — как устроен Health Score: единое число от 0 до 100, которое агрегирует состояние базы и заменяет 30 дашбордов Grafana.
Медленный запрос — это не приговор, это задача со своим решением. Но найти его невозможно, пока планировщик PostgreSQL остаётся для вас чёрным ящиком. Книга Павла Толмачёва «PostgreSQL 16. Оптимизация запросов» даёт то, чего не хватает большинству разработчиков и администраторов: системное понимание того, как планировщик принимает решения, — и практические инструменты, чтобы направить его в нужную сторону.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Результаты углублённого анализа инцидента производительности в высоконагруженной продуктивной среде PostgreSQL, в ходе которого зафиксирован переход от относительной стабильности к комплексной деградации вычислительных ресурсов, подсистемы ввода-вывода и механизмов синхронизации ядра СУБД. Применение pg_expecto с акцентом на использование как инструмента комплексного статистического анализа производительности СУБД и инфраструктуры позволило не ограничиться констатацией снижения операционной скорости, а выявить критическую конкуренцию за буферный кэш (LWLock: BufferMapping), изменения паттернов работы расширений СУБД и скрытые проблемы дисковой подсистемы.
Как только очередной вендор обещает «убить нативные тулзы PostgreSQL», где-то устало вздыхает DBA. Попытка сделать бэкап PostgreSQL «лучше самого PostgreSQL» — это изначально неверная постановка задачи.
Универсальный файловый агент не притворяется глубоко PostgreSQL-aware решением. Его задача в другом: взять нативные механизмы СУБД и превратить их в управляемый и наблюдаемый процесс на уровне всей инфраструктуры.
Вокруг такого подхода обычно сразу возникают неприятные, но правильные вопросы. Кто отвечает за консистентность? Где на самом деле живет PITR? Что будет, если потеряется WAL-сегмент? Можно ли восстановить одну таблицу, а не весь инстанс? И зачем вообще нужен внешний слой поверх pg_probackup, если у PostgreSQL уже есть свои зрелые инструменты?
Под катом — честный разговор о границах ответственности между PostgreSQL и внешней платформой.
В задачах на SQL особенно интересно то, что один и тот же результат часто можно получить несколькими способами – и разница между ними оказывается не только в красоте запроса, но и в его поведении на реальных данных. В этой статье – разбор прикладной задачи про поиск подозрительных логинов из разных стран в пределах двух часов: с вариантом через self join, альтернативой на оконных функциях и сравнением планов выполнения в PostgreSQL.
Несколько лет назад я делал внутренние доклады по PostgreSQL для команды — разбирали транзакции, блокировки и уровни изоляции на живых примерах. Потом ушёл на другой стек, а недавно вернулся к PostgreSQL и пересмотрел свои записи. Материал до сих пор актуален — базовые концепции не изменились. В статье: почему UPDATE из двух сессий «висит», чем Read Committed отличается от Repeatable Read на практике, почему Serializable падает даже без логического конфликта, и как VACUUM на самом деле работает с мёртвыми строками. Всё с SQL-примерами, которые можно повторить.
Привет Хабр! Меня зовут Владимир сегодня я постараюсь исправить ошибку из моей первой статьи про векторный поиск. Основная претензия к статье (два из трех комментариев 😂) была в том, что тема сисек векторного поиска не раскрыта.
В этом материале постараюсь кратко рассказать, что же такое векторный поиск, зачем он нужен, варианты реализации векторного поиска в PostgreSQL и провести сравнительные тесты времени отклика при различных объёмах данных.
Индексы есть, а запросы всё равно тормозят? Или наоборот — индексов слишком много, и они только увеличивают нагрузку на запись?
Многие разработчики и администраторы баз данных попадают в ловушку: ставят B-Tree на всё подряд и надеются на лучшее. Но в highload-системах это может привести к катастрофе.
В этой статье я делюсь реальным опытом работы с PostgreSQL.
Статья будет полезна разработчикам, архитекторам и администраторам, которые хотят не просто «поставить индекс», а понять, как работает PostgreSQL под капотом и как проектировать базы данных, выдерживающие миллионы запросов в секунду.
Apache AGE добавляет графы и Cypher в PostgreSQL. Мы написали бенчмарк, прогнали три типа нагрузки и обнаружили, что поиск кратчайшего пути выдаёт 7 TPS, а вставка вершин деградирует из-за SeqScan в функции проверки существования. Один патч — и TPS вырос в 15 раз. Рассказываем, как до этого докопались.
Когда говорят о качестве статического анализатора, обычно показывают удобные цифры: стало меньше шума, стало больше находок, лучше сработали правила на внутреннем проекте. Проблема в том, что такие оценки слишком легко подогнать под себя.
sa-tests-db полезен ровно потому, что это внешний набор для проверки анализаторов. Он нужен не для красивой демонстрации, а для грубой, неудобной вещи: взять инструмент и посмотреть, как он проходит квалификационный критерий на чужом корпусе, а не на примерах, которые вы сами себе подготовили.
В контексте ГОСТ Р 71207-2024 это особенно важно. Там недостаточно сказать: «в среднем по языку результат хороший». Смотреть нужно по типам ошибок. Если по какому-то типу ошибок анализатор даёт слишком много ложных срабатываний или слишком много пропусков, это уже проблема, даже если общая картинка выглядит прилично.
В современном мире enterprise-разработки часто встречается необходимость реализации распределённых блокировок. Недавно у меня как раз возникла необходимость реализации распределённой блокировки, и я применил пакет RedLock.NET, о чём и хочу рассказать.
Однако когда я писал статью, как-то «слово за слово», она вылилась в сравнительный анализ RedLock.NET и других решений, которые я тоже рассматривал. Мне кажется, все описанные ниже очевидные и не очень решения будет вспомнить вполне уместно. Надеюсь, получится не так уж длинно и будет полезно для читателей.
Под катом вы не найдете откровений, но найдете размышления (для кого-то, возможно, очевидные) разработчика над задачей, которую все вроде знают, как реализовывать, но когда нужно реализовать, то все опять «подзабыли».
