PostgreSQL *

Разбирая взаимоблокировки, Лоренс вспомнил, насколько опасным может быть использование SELECT FOR UPDATE при конкурентном доступе. В этом нет ничего нового, но Лоренс заметил, что многие не знают о режимах блокировки строк в PostgreSQL. Лоренс решил подробно описать, когда следует избегать SELECT FOR UPDATE.

Кругом только и разговоров о том, как бы заставить Postgres работать быстрее, эффективнее, и так далее. Но при этом никто даже не задумывается о том, как бы его замедлить. Само собой, о продуктивности и эффективности парятся в основном те, кому за это платят. Я не из из числа (можете это исправить -- дайте мне знать). На днях я работал над чуть более полезным руководством и в какой-то момент решил, что этому миру нужна такая конфигурация Postgres, которая будет выполнять запросы максимально медленно. Нахрена? Черт знает, но вот что у меня получилось.

Миф о волшебном параметре fast=true жив и здоров, но в распределённых СУБД появляется ещё один — distributed=true. Ни тот, ни другой не спасут, если не пересобрать схему, ключи шардирования, последовательности, запросы и процесс миграции. Мы трезво проходим по всем углам: от выбора ключей и colocated-таблиц до CDC, топологий и ограничений внешних ключей; показываем, где действительно ускорится, а где станет дороже — и что с этим делать.

Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации. 

Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных). 

Делимся практическим опытом миграции PostgreSQL Patroni из Kubernetes на «железные» серверы. Автор рассказывает про выбор метода переноса, настройку standby-кластера, обновление конфигураций и управление трафиком приложений через pgbouncer. Полезно для DevOps и инженеров, которые хотят избежать сбоев и обеспечить плавный переход на bare-metal-инфраструктуру.

На конференции PG BootCamp 2025 был представлен доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций" с рассмотрением проблем при переносе патча с поддержкой 64-битного счетчика с 16 на 18 версию PostgreSQL. В статье описывается история создания патча и почему он есть только в коммерческих форках.

Порой, очевидные вещи таят в себе удивительные сюрпризы. Казалось бы, простые SQL конструкции: «IN» и «NOT IN». Что тут обсуждать-то?

Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.

Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!

Я собрал ядро для Telegram‑ботов и описал архитектуру, которая держится на YAML‑сценариях и очереди в БД. Почему отказался от брокера, как экономлю апдейты в базе, как работает «разблокировщик» цепочек и что это даёт в предсказуемости. Показываю решения и компромиссы без «магии».

TDE бывает разным: от шифрования на уровне TAM до полного кодирования всего кластера и меток tablespace. Мы сравниваем Percona, Cybertec/EDB, Pangolin/Fujitsu и показываем, где теряется производительность и надёжность, а где появляется гибкость. Дополнительно замдиректора департамента разработки продуктов Василий Бернштейн и старший инженер по ИБ Владимир Абрамов расскажут о том, как в Postgres Pro Enterprise реализована ротация ключей без полного переписывания таблиц и почему выбран AES‑GCM.

Привет, Хабр! Наверняка каждый разработчик или администратор сталкивался с ситуацией, когда для проверки гипотезы или нового функционала срочно нужна «чистая» база данных. Приходится либо искать свободный сервер, либо разворачивать всё локально, тратя время на установку и настройку. А если таких тестовых баз нужны десятки для команды или разных команд? У наших клиентов мы видели целый зоопарк из PostgreSQL разных версий и конфигураций, поддержка которых превращалась в головную боль. Именно эту проблему — создание «одноразовых» и легковесных баз по одному клику — мы и решили. Меня зовут Сергей Гонцов, я занимаюсь развитием СУБД, основанной на PostgreSQL, которая совсем недавно перешла «под крыло» Arenadata и называется теперь Arenadata Prosperity (ADP). В этой статье расскажу нашу историю, как мы готовили свой DBaaS-сервис.

Привет, Хабр! На связи Марк — ведущий архитектор группы компаний «ГлоуБайт». В этой статье я поделюсь результатами нагрузочного тестирования, которое мы с коллегами провели для сравнения Greenplum 6 с Greenplum 7 и Cloudberry.

Когда вы впервые сталкиваетесь с задачей деплоя, процесс может показаться сложным и пугающим. Докер-образы, безопасность, container registry, а тем более Kubernetes — для новичка это настоящая головная боль. Именно поэтому наши партнеры из Amplicode решили написать статью, которая поможет вам максимально просто и быстро задеплоить ваше первое Spring-приложение в облако.

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

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

Сегодня разбираем COPY в PostgreSQL. Это рабочая лошадка для массовой загрузки и выгрузки данных.

41 ТБ/сутки по маршруту Oracle → Postgres Pro без остановки исходной системы — это не теория, а цифры последних тестов. Мы разложили миграцию на три этапа: быструю начальную загрузку, CDC из redo-логов и валидацию, и собрали их в ProGate. Как устроен конвейер, почему Go и где прячутся узкие места — расскажем в статье.

В предыдущей статье я разбирал некоторые нюансы Postgres, касающиеся индексов и параллельных воркеров. Текст этот вызвал достаточно оживленное обсуждение и один из комментаторов предложил значительно более эффективный индекс, нежели были рассмотрены в статье. Сравнение эксплейнов не позволяло сразу понять причины его превосходства и потребовалось дополнительное расследование

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

В статье детализируется часть доклада Максима Старкова на конференции PG BootCamp, которая прошла в апреле в Екатеринбурге. Описываются признаки таблиц и индексов, при работе с которыми может возникнуть проблема выбора худшего индекса, а также рассматривается пример, демонстрирующий, что строка "Buffers" характерна для определения эффективности выполнения запроса (в 18 версии PostgreSQL "Buffers" будет показываться в планах по умолчанию).

Как я пришел к написанию собственного пакета go, столкнувшись с отсутствием синтаксического сахара в языке и трудностях при разработке приложений в production с отсутствием команды инфраструктуры на go.

Привет, меня зовут Павел, я являюсь разработчиком в DD Planet. Сегодня хочу поговорить об одной частой ситуации. Если ваш web сервис работает по подпискам или с регулярными платежами — рано или поздно встаёт вопрос: брать готовое решение или сделать своё.