В статье разбирается практический подход к мониторингу managed PostgreSQL в Yandex Cloud с использованием экспортёра pgSCV. Показано, как выстроить сбор метрик так, чтобы он не создавал дополнительной нагрузки на базу данных, масштабировался вместе с инфраструктурой и оставался управляемым.
Часто при замедлении работы базы данных первым решением кажется увеличение вычислительных ресурсов: больше ядер, памяти, быстрые диски. Однако существует и другой, более экономичный путь — заглянуть глубже, на уровень операционной системы, управляющей этими ресурсами.
Данная статья — это практический разбор реального кейса, где скрупулёзная настройка параметров подсистемы ввода-вывода, кэширования и планировщика задач Linux позволила поднять производительность PostgreSQL на впечатляющие 65%. Без замены железа, без увеличения лицензий, только за счёт грамотной оптимизации «фундамента», на котором работает СУБД.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
За 5 лет работы в B2B и B2C сегментах у телеком-провайдеров я столкнулся с одной из проблем: абоненты годами сидят на архивных дорогих тарифах или пользуются услугами операторов, которые не идут на уступки, не снижают цены на тарифы, пользователи просто не знают, что в их же доме есть альтернативные провайдеры с тарифами более выгодными для них.
Я решил объединить свой опыт в телекоме с навыками в программировании. Так появилась идея по парсенгу тарифов. Цель — создать инструмент, который автоматически мониторит провайдеров, избавляя пользователей от ручного сравнения и помогая им находить оптимальные условия по тарифу.
Сейчас я работаю аналитиком БД, параллельно изучаю архитектуру, построение данных. Решил начать проект с проектирования структуру на PostgreSQL по схеме "Звезда". Таблицей фактов у меня будет таблица со связью города с провайдером, таблицы измерений – таблица с информацией о тарифах, городами и провайдерами.
Существует опасное заблуждение, что «ванильный» Open Source — это серебряная пуля для энтерпрайза. Однако жесткий краш-тест последних лет показал: когда уходят привычные гиганты вроде Oracle, чистый Postgres превращается в тыкву под нагрузками крупного бизнеса. Руководитель отдела технического консалтинга Postgres Professional Марк Ривкин делится своим авторским видением того, почему нам приходится заново изобретать велосипеды, дописывая миллионы строк кода в ядро, и почему будущее за конвергентными системами. Дисклеймер: это частный взгляд эксперта.
Привет! Хочу рассказать о своем новом небольшом проекте - pg-status. Это очень легкий и производительный микросервис, который помогает определять статус хостов postgresql. В первую очередь его задача - помочь вашему backend найти живого мастера и достаточно синхронную реплику.
Привет!
Если вы администрируете PostgreSQL или хотя бы раз пытались понять, почему ваш отчёт выполняется полчаса, то наверняка натыкались на интересную настройку work_mem. Одна строчка в конфиге, а может превратить черепашку в гепарда. Или наоборот, положить сервер.
Здесь я представляю результаты работы над первым шагом к внедрению временных таблиц в схему параллельного выполнения запросов в PostgreSQL - тестирование последовательной записи и чтения temp buffers. В системный каталог PostgreSQL добавлены функции измерения операций сброса буферов, и проведены тесты. Для целей оптимизатора выполнена оценка коэффициента стоимости сброса буфера временной таблицы на диск относительно уже существующего DEFAULT_SEQ_PAGE_COST. Выполнена оценка стоимости простого обхода temp buffers (dry-run). Измерения показывают, что последовательная запись примерно на 30% медленнее чтения. На основе этих результатов предложена формула оценки стоимости.
В мире PostgreSQL, как и в автоспорте, не существует единой идеальной стратегии для всех трасс. Выбор интервала контрольных точек (checkpoint_timeout) — это пит-стоп: можно заезжать часто для максимальной скорости на прямых, но рискуя потерять время на самом заезде, или реже — для стабильного и предсказуемого ритма всей гонки. Всё зависит от типа «трассы» — характера нагрузки на вашу базу данных.
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
Ivory теперь поддерживает LDAP и OIDC/SSO наряду с базовой аутентификацией, что значительно упрощает интеграцию с существующей инфраструктурой идентификации. Для каждого провайдера предусмотрены возможности тестирования подключения, а пользователям можно настроить несколько вариантов входа.
Добавлена полная система разрешений для контроля доступа к определенным кластерам, запросам и настройкам. Новый интерфейс управления разрешениями позволяет администраторам предоставлять и отзывать доступ, а пользователи могут запрашивать необходимые им разрешения. Это делает Ivory подходящим для больших команд с разными уровнями доступа.
Postgres Pro Enterprise 18.1.1
До Нового Года успела выйти 18-я версия Postgres Pro Enterprise - Postgres Pro Enterprise 18.1.1. Версии Postgres Pro Standard 18.1.1 и - до неё - Postgres Pro Standard 18.0.1 следовали за соответственно. А - как видно из номера - Postgres Pro Enterprise 18.1.1 - перепрыгнула через ступеньку. Поэтому, если будет желание отследить изменения, унаследованные от Standard и PostgreSQL, надо сравнивать сразу с 2 версиями каждой. Мы же здесь не будем фокусироваться на формальностях и просто приведём (неполный, конечно - полный слишком велик для нашего жанра) список нового.
Добавлена возможность создавать таблицы, которые разделяются на секции при помощи внешнего ключа. Внешний ключ используется как ссылка на родительскую секционированную таблицу и определяется в предложении PARTITION BY REFERENCE.
Обновлены модули, в том числе BiHA. В ней много важных изменений:
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
В начале декабря я публиковал статью про Postgresus 2.0 — инструмент для резервного копирования PostgreSQL. С момента этой статьи пришло много запросов на добавление других баз данных, много положительной обратной связи от пользователей и набралось больше 1000 звёзд на GitHub.
А потом я узнал, что нарушил торговый знак 🥲. Оказывается, нельзя брать первое понравившееся название — и использовать его. Точнее можно, но с оговорками.
В итоге было принято решение о маленьком ребрендинге. Теперь Postgresus — это Databasus. И поддерживает другие базы: MySQL, MariaDB и MongoDB (при этом оставляя основной фокус на PostgreSQL).
Ниже — детальнее, что из себя представляет проект и почему произошло переименование.
В своей практике мы можем сталкиваться с хранением и поиском информации задаваемой в интревальном формате. Например: срок действия акций, тарифы на доставку и прочее. В статье мы подружим Spring JPA и Range Types.
Наверняка у вас тоже было такое, что сервис работает себе спокойно, радует пользователей своей стабильностью и производительностью, а вас зелёным мониторингом. А в следующий момент хлоп - и нет его. Вы на панике смотрите в логи ошибок, а там или невнятный сегфолт, или просто ничего. Что делать – непонятно, и вообще надо прод спасать, поэтому вы поднимаете его обратно и всё работает как и раньше. Вы ещё пытаетесь разобраться в причинах случившегося, но со временем переключаетесь на другие задачи, а этот случай отходит на дальний план или вообще забывается.
Но это всё хорошо когда вы один, а вот если у вас много клиентов, то рано или поздно у вас возникает ощущение что что-то не так и надо разобраться с этими всплесками энтропии, чтобы найти первопричину подобных событий.
В этой статье описано наше исследование длиною в год, из которого вы узнаете, почему PostgreSQL(и любое другое приложение) может падать из-за бага в ядре Linux, причём тут XFS и почему очистка памяти может быть не так полезна, как вы о ней думали.
Привет Хабр! Меня зовут Михаил. Я backend-разработчик в команде Биллинга в Тензоре.
Эта статья — обзор вариантов индексации JSON и JSONB-полей и оптимального поиска текста в них, который мы проделали вместе с командой. Так как используем PostgresSQL, все варианты валидны для него.
Несколько лет назад я трудился в проекте, где основной биллинг работал на Oracle. Однажды коллега захотел поправить тестовые начисления в таблице abon_charges и выполнил такой запрос:
UPDATE abon_charges SET amount = 0 WHERE service_id = 123 AND v_abon_id = v_abon_id;
На первый взгляд — ничего страшного. Но v_abon_id = v_abon_id истинно для любой строки. Oracle это не игнорирует. Условие становится:
WHERE service_id = 123 AND TRUE
Так запрос обнулил абсолютно все суммы для service_id=123 за десятки месяцев. В таблице было около 1,8 млн строк по этой услуге.
С такой неприятностью в Oracle может помочь механизм Oracle Flashback. Вкратце: находим проблемную транзакцию, в отдельной сессии включаем чтение таблицы на момент до обновления, снимаем копию в отдельную таблицу и отдаём её нашему виновнику для решения проблемы :).
Мы починили всё без простоя и полного восстановления всего кластера. С тех пор мне всегда хотелось иметь такой «точечный флэшбэк» и в PostgreSQL. Особенно в системах, где восстановление базы на несколько терабайтов может занимать часы. И вот недавно мне довелось организовать такое решение в нашем продукте Platform V CopyWala. Это инструмент для бэкапа от СберТеха, который работает с PostgreSQL. Покажу, как всё устроено.
Осторожно, спойлеры! Не читайте, пока хотите решить задачу самостоятельно.
В этой челлендж-серии статей, начатой с прошлогоднего эвента, попробуем использовать PostgreSQL как среду для решения задач Advent of Code 2025.
Возможно, SQL не самый подходящий для этого язык, зато мы рассмотрим его различные возможности, о которых вы могли и не подозревать.
Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.
UUIDv4 как первичный ключ в PostgreSQL обычно ругают за «случайность» — но за этим словом прячется конкретная физика: сплиты страниц B-дерева, рыхлый листовой уровень, фрагментация и лишний случайный I/O при чтении. В PostgreSQL 18 появился UUIDv7 — и это хороший повод посмотреть на проблему не на уровне вкусов, а на уровне того, как реально устроены индекс и heap: от корреляции и ctid до статистики страниц и плотности листьев.
Проблема при использования pg_varables в PostgeSQL 18, приводящая к ошибкам работы с памятью и искажением данных. В публикации описан способ решения проблемы.
