PostgreSQL *

«Современная производительность — это сложный пазл, где метрики СУБД, дисковые операции, потребление CPU и сетевые задержки тесно переплетены. Традиционное нагрузочное тестирование часто дает лишь часть ответа, заставляя нас собирать данные из десятка разных источников. В этой статье мы рассмотрим, как расширение pg_expecto становится единым источником истины, объединяя метрики инфраструктуры и PostgreSQL в едином контексте. Узнайте, как превратить разрозненные данные в целостную картину и получить точный ответ на вопрос: где на самом деле кроется узкое место вашей системы?»

Привет, Хабр.

Думаю, у каждого, кто искал работу, есть этот "любимый" запрос на hh. Вбиваешь "Python Developer", ставишь фильтр "нет опыта", а тебе вываливается 500 вакансий "Senior Analyst", где в требованиях "базовое знание SQL, Python будет плюсом".

Ручной разбор этой каши убивает время и мотивацию. Мой друг Роман (он IT-рекрутер и карьерный консультант) постоянно рассказывает, как кандидаты выгорают еще до первого собеса именно на этом этапе.

Я решил, что хватит. Пора автоматизировать рутину. Казалось бы, 30-минутная задача: дернул API, отфильтровал, откликнулся. Как же я ошибался. Сегодня расскажу, на какие грабли наступил, пока пилил «Аврору» - свой инструмент для автоматизации этого ада.

Очередной чат, и к тому же на rust?! Да, yet another. И да, в этой статье не будет каких-то новых откровений системного программирования с написанием своего фреймворка для работы со сетью на уровне драйверов или других испытаний. Этот альманах про мой первый опыт в веб-разработке, который может быть полезен для других новичков, ведь тут мы затронем помимо злосчастного rust такие вещи, как devcontainer, REST API, идентификацию-аутентификацию-авторизацию, WebSockets, SSE, юнит и интеграционные тесты, некоторые паттерны, логирование и прочее.

В мире СУБД общепринятая догма гласит: «Индексы ускоряют запросы». Но что, если в погоне за производительностью мы создали себе проблему? В этой статье, на практике показан парадоксальный сценарий, при котором удаление первичного ключа у таблицы pgbench_branch и последующее увеличение стоимости запроса привели к впечатляющему росту общей производительности PostgreSQL под нагрузкой. Слепое следование правилам может быть опаснее их осознанного нарушения. СУБД не так просты, как может показаться.

Как вы думаете, сколько человек документирует продукты в Postgres Professional? 50? 100? А вот и нет — всего десять. Рассказываем, как команде техписателей удается управлять сотнями файлов, почему их работа — это квест, и как они успевают контрибьютить в ванильный PostgreSQL.

Миграция PostgreSQL — редкий проект, где «быстро и безболезненно» почти никогда не совпадают. Дамп/восстановление годится для сотен гигабайт, потоковая репликация по WAL — для тех, у кого есть к ней доступ. Но когда простоя не хочется, а WAL недоступен, остаётся третий путь — логическая репликация.

В этом материале — практический сценарий: как заранее перенести схему, обеспечить уникальную идентификацию строк (PK/уникальный индекс/REPLICA IDENTITY FULL), настроить публикации и подписки, следить за первичной загрузкой через pg_stat_subscription, корректно остановить запись на источнике и синхронизировать последовательности.

Лайфхаки для миграций, оптимизации и избегания граблей

Реальные лайфхаки и проверенные практики по миграциям, оптимизации запросов, управлению индексами и обратной совместимости кода. Узнайте, как:

• Не сломать прод при миграции.
• Избежать N+1 и других проблем SQL-запросов.
• Планировать откаты и работать безопасно на высоконагруженных БД.

Давайте честно – пока что Postgres редко используется для действительно больших и нагруженных баз. Этому множество причин, но главная формулируется просто: «не тянет».

У каждого есть своя граница, где Postgres ещё применим, а дальше —уже нет. Обычно это где-то между одним и пятью терабайтами, дальше жить с этим «больно».

База просто не может обработать большой объем данных с той скоростью, которую способны выдать диски.

И вот — Postgres 18, впервые за долгое время, предлагает не косметическую, а фундаментальную новинку. То, что в Oracle есть уже 20+ лет — асинхронный ввод-вывод (аsync IO).

Попробуем посмотреть async IO и ответить на вопрос - стал ли Postgres ближе к «взрослым» нагрузкам?

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

Определить характерные события ожидания (wait_event), оказывающие влияние на снижение производительности СУБД в ходе нагрузочного тестирования при наличии лишних индексов на тестовые таблицы.

В статье рассматривается создание кластера Patroni последней версии 4.0.7 и etcd 3.6.5 в контейнерах docker. Приводится пример, когда Patroni не может автоматически восстановить и запустить кластер PostgreSQL. 

Patroni в докере

Задача запуска Patroni в докере обсуждалась на реддит и гитхаб. Приводился пример наиболее простой сборки batonogov/patroni-docker, которая состоит из 7 контейнеров: трёх с кластером etcd и трёх с PostgreSQL 17 под управлением Patroni (мастер и две реплики), один контейнер с HAProxy.

Каково это — стоять у истоков того, что сегодня стало технологическим фундаментом всего Рунета? В новом большом интервью «В Офисе» — Олег Бартунов, один из главных мейнтейнеров PostgreSQL и основатель компании Postgres Pro. Он вспоминает, как в 90‑х собирал дистрибутивы ОС через знакомых в КГБ, разбирал «кишки» компьютеров ради науки и писал письма Сергею Брину — задолго до появления Google и GitHub.

В подкасте  «В Офисе» я, Ваня Ботанов, автор телеграм-канала «Деплой» вместе с Олегом Бартуновым. Поговорили о том, с чего начинался Postgres, каково быть ядром мирового опенсорса, что изменилось в сообществе после 2022 года. Это первая часть двухчасового разговора на сложные темы – умер ли Open Source и как из учёного и первооткрывателя звёзд стать бизнесменом.

Одна из открытых пока задач в области баз данных - поддержание базы данных в консистентном состоянии одновременно на нескольких экземплярах СУБД (узлах), принимающих клиентские соединения независимо друг от друга. Суть проблемы заключается не в том, чтобы синхронизировать состояние удалённо по сети, а в том, что в случае отказа одного из узлов такой системы остальные должны продолжить свою работу без перерыва: принимать соединения, коммитить транзакции не потеряв при этом консистентность. Аналогией для случая одного экземпляра СУБД здесь может быть, к примеру, обеспечение работы при отказе планки оперативной памяти или прерывающемся доступе к нескольким ядрам процессора.

Здесь я хочу возобновить обсуждение проблемы мультимастера на базе Postgres: его практическую ценность, реализуемость, стэк технологий, которые нужно создать. Возможно, что поставив проблему более узко, мы сможем прийти к решению, которое будет полезно для отрасли...

В статье я расскажу о практических кейсах и сложностях, возникающих (и возникавших) в процессе миграции данных между СУБД (Oracle -> Postgres), а также о собственном инструменте миграции данных, который вы также можете попробовать.

В этом руководстве мы разберем непонятности вокруг Unicode и узнаем, как строить надёжные, интернациональные Java-приложения. Разберём теорию, укажем на подводные камни, а затем соберём «Глобальный сервис приветствий» на Quarkus, который переживёт весь хаос реального текста.

К концу статьи вы разберётесь с тем,

– как устроен Unicode и как Java на самом деле хранит текст;
– почему длина строки и перебор символов сложнее, чем кажется;
– как нормализация предотвращает неприятные несоответствия;
– как настроить REST-сервис и базу данных для безопасной работы с Unicode.

PostgreSQL 18

Всё, уже официальная версия.

Загрузить,

замечания к выпуску (release notes),

для прессы,

безопасность,

версионная политика,

контакты,

дайте денег.

Как всегда, все основные особенности обсудили ещё задолго до официальной, начав с первых бет (мы, например, говорили о некоторых статьях на эту тему ещё в номере Postgresso 3-4 за 2025, когда вышла самая 1-я бета).

Вот что подчёркивают в официальном релизе:

Я прочитал статью, и меня поразило, сколько сомнительных решений можно использовать для одной простой задачи.

В этой статье я расскажу, как правильно создать сервис для конкурентных обновлений остатков данных в базе данных. Буду использовать .NET, C#, Entity Framework и PostgreSql.

В мире, где абстракции правят бал, а скорость важнее эффективности, говорить о C — значит идти против течения. Для многих это «устаревший» язык с ручным управлением памятью и «опасными» указателями. Но что, если именно эти его особенности — не минусы, а ключи к системному программированию, где нет права на ошибку? Программистом Postgres Professional с 22-летним стажем Максим Орлов убеждён, что C — не про мгновенный дофамин и быстрые прототипы, а про суть, контроль и философское понимание того, как действительно работает железо. Погрузитесь в историю любви к C, которая началась с раздражения на Pascal, и узнайте, почему этот «бастион спокойствия» актуален и сегодня.

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.

Традиционные подходы к генерации SQL-запросов часто полагаются на инструктированные языковые модели, но они могут быть неэффективными и неточными. Мы рассмотрим новый подход, основанный на использовании Reinforcement Learning для дообучения моделей, который может улучшить точность и эффективность генерации SQL.