PostgreSQL *

Что общего у массового применения конфигураций, встроенной поддержки OpenTelemetry и управления HA-кластерами в пару кликов? Всё это — части пазла, который мы собираем, чтобы сделать администрирование PostgreSQL по-настоящему удобным и безопасным. Выход версии Postgres Pro Enterprise Manager (PPEM) 2.3 стал важной вехой в развитии нашего графического интерфейса. Мы добавили поддержку пользовательских пресетов, переработали систему алертинга и усилили RBAC-модель управления доступом. Разбираем ключевые нововведения релиза, которые помогут навести порядок в зоопарке конфигураций и спать спокойно, зная, что система сама предупредит о проблемах.

Меня зовут Дмитрий Фатов, я разработчик в Газпромбанке — вместе с командой создаю платформу G2, на которой мы разрабатываем свои решения. Одно из решений — SaaS, система, в которой есть внешние интеграции через xml. До какого-то момента к нам приходило максимум 30 тыс. документов в одной выгрузке, но после подключения очень крупного клиента в одной выгрузке начали получать до 2 млн документов. Это около 4 млн записей в базе данных. 

SLA на обмен данными со сторонними системами — меньше пяти минут. И мы в него не укладывались, нужно было срочно оптимизировать бизнес-процессы, среди которых весомой частью была именно вставка данных. 

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

Привет, Хабр! Меня зовут Валерий Пташкин, я руководитель направления в трайбе «Потребительское Кредитование» в Сбере. Статью я подготовил вместе с моими коллегами — Кириллом Макаровым и Евгением Беляевым.

Наш продукт отвечает за хранение клиентских заявок на потребительские кредиты, заявок кредитного потенциала, автокредитов, ипотечного кредитования и так далее. И в этом году мы перевели работу нашего модуля хранения с Oracle на СУБД Pangolin (сборка PostgreSQL с доработками от СберТеха).

При переезде у нас было несколько критичных требований к СУБД: способность держать достаточно высокую нагрузку (4 тысячи запросов в секунду), при этом иметь время отклика не более 100 мс для 99 % запросов, и обеспечивать максимально высокую доступность нашего сервиса как системы уровня mission critical.

В этой статье мы расскажем про состояние нашей инфраструктуры, этапы миграции, и коснёмся возможных нюансов и потенциальных рисков. Это будет полезно тем, кто тоже планирует переезд на СУБД Pangolin или другой форк PostgreSQL. Уверен, многие рекомендации пригодятся и пользователям стандартного PostgreSQL. Итак, начнём.

Привет, Хабр! Меня зовут Александр Гришин, я руководитель по развитию продуктов хранения данных в Selectel. Сегодня я предлагаю продолжить разбираться с PostgreSQL и заглянуть еще глубже в эту кроличью нору. Посмотрим, что происходит под капотом СУБД во время записи строк, поверхностно разберем, как устроены страницы памяти, что такое tuple, tuple chain, fillfactor, VM и FSM. Эти знания помогут разработчикам не только понимать, как работает база данных, но и эффективно управлять ее производительностью в продакшене.

Если вы начинающий DBA, разработчик, инженер или архитектор облачной инфраструктуры, эта статья для вас. Погнали?

Всем привет!

Меня зовут Александр Борисов, я главный эксперт по технологиям в СберТехе. В статье расскажу про свой алгоритм, который позволил повысить скорость Unicode в PostgreSQL 18. На эту тему уже выпущен патч Optimization for lower(), upper(), casefold() functions, принятый сообществом PostgreSQL.

Статья будет интересна разработчикам, которые работают с большими объёмами текстовых данных, а также всем, кто следит за развитием PostgreSQL и интересуется оптимизацией.

Начнём с краткого обзора: что же удалось ускорить в PostgreSQL?

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

Команда Go for Devs подготовила перевод статьи о том, почему большинству проектов не нужна Kafka, «веб-масштабные» очереди и зоопарк из пяти баз данных. Автор на бенчмарках показывает, как далеко можно уехать на одном Postgres — и заодно разбирает, почему карго-культ масштабирования и «инфраструктура ради резюме» только мешают делать работу.

Ваш сервис отправил сообщение в RabbitMQ, но в момент коммита транзакция в базе данных откатилась. Классический кошмар распределенных систем, порождающий данные-призраки и часы отладки. Обычно эту проблему решают сложным кодом, двухфазными коммитами или просто надеждой на лучшее. А что, если бы откат транзакции в PostgreSQL мог автоматически «откатить» и отправку сообщения, вернув его в очередь без единой строчки вашего кода? Рассказываем, как это работает.

Недавно я изучал детали реализации взаимодействия клиента PostgreSQL с базой данных и был удивлён, насколько легко просматривать трафик PostgreSQL с помощью wireshark. Когда я поделился своим удивлением в социальной сети, меня попросили привести пример того, как это сделать.

Недавно я получил статус Major Contributor в проекте PostgreSQL. Это довольно радостное для меня событие и интересное, поэтому коллеги попросили написать статью об этом. А чтобы я не сомневался — заботливо составили список достижений за меня. Получилось замечательно, но публиковать от своего имени статью вида «как я крут» я не хочу. Я совсем не против про это говорить, и из каждого утюга вещаю про разные технологии, сделанные моей командой или вот прям вообще мной. Но только в контексте «как использовать эти технологии», либо в узком кругу или личной беседе. 

Я решил написать другую статью: что у меня не получилось. Писал довольно спешно, поэтому, возможно, местами будет понятно только специалистам. Не расстраивайтесь, если что‑то неясно и пришлось гуглить. А вот если всё понятно — возможно, стоит меньше смотреть в монитор и чаще трогать траву.

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

Некоторые из IT-компаний говорят, что поддерживают open source. На деле это нередко означает использование чужого кода и PR-активность. Мы считаем, что настоящий вклад — это коммиты в ядро. И чтобы делать это системно, мы открыли инженерный центр не в столичном бизнес-парке, а в месте, где фундаментальная наука — часть культурного кода. Рассказываем, почему будущее системного программирования мы строим в новосибирском Академгородке.

Пополнение в списке контрибьюторов:

New PostgreSQL Contributors 2025

Major Contributors:

Андрей Бородин (Andrey Borodin, Яндекс.Облако, наши ПОЗДРАВЛЕНИЯ!
Якоб Чемпион (Jacob Champion, EDB),
Йелте Феннема-Нио (Jelte Fennema-Nio Motherduck, DuckDB),
Роберт Трит (Robert Treat pgtreats, за общественную деятельность).

Просто новые контрибьюторы:

Эндрю Кейн (Andrew Kane),
Энди Фэн (Andy Fan),
Ханс-Юрген Шёниг (Hans-Jürgen Schönig),
Хиан Хе (Jian He),
Марко Нанчиарини (Marco Nenciarini),
Майкл Голдберг (Michael Goldberg),
Сара Конвей (Sarah Conway).

Привет, меня зовут Артем, и я работаю в Авито с 2016 года. Это вторая часть истории про шардирование сервиса объявлений Авито Доставки, где мы расскажем о реализации шардирования и полученном результате.

Я построил полноценную образовательную платформу для изучения иврита — с интерактивными тренажерами, умным словарем на 4000+ слов и системой подписок. В статье рассказываю о нетривиальных технических решениях, архитектурных выборах и ошибках, которые пришлось исправлять по ходу.

Продукт: hebrewglot.com

Стек: Next.js 15, TypeScript, PostgreSQL + SQLite, Stripe, NextAuth

Вступление: Почему я вообще это пишу?

Представьте: нужно обновить базу данных размером с небольшое озеро — целых 10 ТБ. Классические методы тут не работают. Сделать дамп и восстановить? Это ж на неделю бизнес встанет. Обновлять «в лоб» с 11-й до 17-й версии? Это рискованно и надолго всё упадёт.

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

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

Привет, меня зовут Артем, и я работаю в Авито с 2016 года. Начинал как тестировщик, затем вырос в backend-инженера, с 2019 года пишу на golang, а сейчас руковожу командой разработки в Авито Доставке в роли техлида. В этой статье поделюсь опытом шардирования нашего основного сервиса delivery-item: зачем мы это сделали, как подошли к задаче, с какими граблями столкнулись и как всё выглядит спустя почти два года.

Когда мы пишем запрос, СУБД делает гораздо больше, чем просто ищет данные. Она оценивает десятки сценариев выполнения, сравнивает стоимость операций и выбирает оптимальный путь к результату. От этого выбора зависит, будет ли запрос выполняться секунду или минуту. Почему одни системы находят лучший план, а другие выстраивают менее эффективный алгоритм? Попробуем разобраться, как планировщики СУБД принимают решения и что определяет их эффективность.

Всем привет! Меня зовут Алексей Кременьков, я старший разработчик в Яндекс Почте. В этой статье расскажу, как мы работаем с большим количеством шардов PostgreSQL: как создавали собственный сервис динамического шардирования Sharpei, как развивали инфраструктуру под него и как проходил переезд на облачное решение. В конце разберёмся, какие плюсы и минусы мы смогли найти в этом решении.

Транзакции — не про «магическое ACID», а про конкретную механику согласованного доступа к данным под нагрузкой.

Эта статья объясняет как реально работают уровни изоляции и чем отличаются популярные СУБД на практике.

Мы разберём:

Можно ли смоделировать хаос пуассоновских потоков бронирований и конечный автомат состояний рейса (от «по расписанию» до «приземлился») целиком внутри PostgreSQL? Мы решили, что для создания идеальной учебной базы данных — можно. Вместо старых статичных таблиц мы построили генератор, имитирующий жизнь глобальной авиакомпании. Рассказываем, зачем это было нужно и почему старая база на 2,5 ГБ перестала справляться с задачами.