Обновить
64K+

PostgreSQL *

Свободная объектно-реляционная СУБД

179,56
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Как мы строим хижину Postgres Pro

Уровень сложностиПростой
Время на прочтение15 мин
Охват и читатели11K

Хижину на высоте 3 930 метров в Кыргызстане пришлось сделать шире, чем в чертежах. Причина простая: матрасы оказались на несколько сантиметров больше, чем рассчитывали. К этому моменту материалы уже лежали на леднике: их привёз вертолёт, а недостающее мы дотаскивали в рюкзаках. Я работаю в Postgres Professional и около двадцати лет хожу в горы. Сейчас вместе с друзьями строю здесь новую хижину для альпинистов. Пока мы утепляем стены и собираем электрику, на ней уже ночуют люди, а по ночам заглядывают куницы. Для них мы закрыли все щели, но куницы всё равно нашли путь.

Читать далее

Новости

Настройка HAProxy для автоматического определения ролей экземпляров PostgreSQL и защиты от split brain

Уровень сложностиСложный
Время на прочтение18 мин
Охват и читатели10K

HAProxy должен выполнять проверки, чтобы определить роль экземпляров PostgreSQL: мастер или реплика, чтобы направлять соединения на подходящие сервера. В статье описываются способы настройки HAProxy для обнаружения переключения ролей экземпляров PostgreSQL через Patroni REST API, через параметр in_hot_standby, передаваемый сервером сразу после аутентификации клиента, или запросом select pg_is_in_recovery(); Два последних способа используются, если Patroni поставлен на паузу или не используется.

Читать далее

Бэкап был, восстановить было нечего: как pg_dump молча собирал битые дампы из‑за row‑level security

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели6.2K

Если у вас PostgreSQL с включённым row-level security и ночной pg_dump по таймеру, откройте каталог с бэкапами и сравните размеры вчерашнего и позавчерашнего дампов. Если файлы подозрительно одинаковые и маленькие, возможно, у вас нет ни одного рабочего бэкапа. У нас так было не меньше двух недель.

Читать далее

Векторизованное колоночное исполнение запросов в PostgreSQL 19

Уровень сложностиСложный
Время на прочтение21 мин
Охват и читатели7.9K

На прошлой неделе я перенес форк Apache Cloudberry на PostgreSQL 19 в виде набора расширений и рассказал, где этот порт проигрывает оригинальному форку. Впрочем как и Cloudberry на ClickBench современные колоночные движки обгоняют его на порядок. И дело тут не в реализации MPP, а в исполнителе PostgreSQL - он работает с кортежами в памяти СУБД. Каждый кортеж проходит отдельно, значение проходит через fmgr, а сегменты кластера лишь добавляют число процессоров на котором крутится тот же самый цикл по строкам таблицы.

Следующий логичный шаг для ускорения - векторизованный исполнитель в PostgreSQL. В открытом коде Apache Cloudberry его нет: от закрытого движка в репозитарии остались только следы - флаг create_vectorization_plan, который планировщик всегда передает как false, а также узел WindowHashAgg без реализации и адаптер PAX под VEC_BUILD, который не компилируется. Проектировать придется самому и, конечно, снова в виде расширения постгреса. Так появился pg_vexec - набор расширений для PostgreSQL 19.

Проект не требует модификации ядра PostgreSQL даже при использовании планировщика ORCA в одноузловой конфигурации без координатора на ванильной сборке PostgreSQL. Модуль gp_orca из порта Cloudberry теперь собирается без pg_core и прочих потрохов greenplum и патчей ядра СУБД, а vexec превращает ORCA в векторный планировщик с исполнителем в “одном флаконе”: его оптимизатор оценивает стоимости теперь и векторных узлов, а транслятор генерирует эти узлы в плане. Патчи ядра не нужны, только если не нужна функциональность и колоночное хранение данных таблиц из Cloudberry. Если же загрузить расширение Cloudberry на пропатченном ядре постгреса, то vexec может более эффективно читать и писать колоночные PAX и ao_column, без лишних конвертаций из и в строки, а Motion тогда может передавать между сегментами данные сразу в колоночном формате Arrow IPC.

И к постгресу можно подключаться как по привычному pgwire протоколу, так и по более современному Flight SQL, что могут оценить те кто будет запускать ML модели на данных из PostgreSQL. Как минимум при загрузке данных в polars скажут мне спасибо!

Читать далее

Таймаут в секунду, запрос на 43 секунды: пять ловушек PgBouncer в режиме транзакций

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели7.1K

В настройках клиента базы стоял statement_timeout в одну секунду, а запрос выполнялся больше сорока. Таймаут выглядел включённым и не действовал. У этой поломки нашлись четыре родственницы. Пулер в тексте ошибки назвала только одна. Остальные выглядели как пропавшая таблица, недоступная база и простой после выката.

Читать далее

Почему COALESCE ломает план PostgreSQL и как научить планировщик считать его селективность?

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели88K

Один COALESCE в условии способен превратить быстрый Hash Join в мучительно долгий Nested Loop. Убрать оператор COALESCE — и оценка стоимости плана упадёт в десятки раз, а запрос отработает мнгновенно. В данных при этом не меняется ничего: та же колонка, та же статистика, та же селективность, просто без COALESCE планировщик её видит, а с ним — перестаёт. Обсудим, как один COALESCE в JOIN роняет план, почему PostgreSQL теряет на нём оценку, и посмотрим на патч, который учит планировщик считать селективность COALESCE из имеющейся статистики.

Читать далее

Параллельное (конкурентное) создание индексов на секционированных таблицах

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели5.2K

Привет, Хабр! Сейчас многие компании активно занимаются вопросом «импортозамещения» и мне выпала задача отвечать за поддержку и миграцию сервиса логирования. Хочу рассказать с какой проблемой я столкнулся при доработке сервиса логирования на PostgreSQL, а именно, создание индекса на высоконагруженной таблице.

Читать далее

Резервирование кластера Greengage DB. Часть 3

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели5K

В данной статье рассмотрим сложные сценарии восстановления кластера Greengage DB, в которых кластер восстанавливается на новом окружении.

Читать далее

PostgreSQL 19: Коммитфест 2026-03 Часть 5.4 (SQL, DEV1, DEV2)

Время на прочтение7 мин
Охват и читатели6K

Завершаем обзор мартовского коммитфеста 19-й версии. В четвертой и последней статье серии рассмотрим изменения, относящиеся к языку SQL и материалам курсов DEV1 и DEV2.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2)

Часть 5.3 (DBA3, DBS)

Часть 5.4 (SQL, DEV1, DEV2) – мы здесь 🙂

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Читать далее

Код-ревью самому себе через год: 8 архитектурных ошибок соло-проекта

Уровень сложностиСредний
Время на прочтение18 мин
Охват и читатели5.2K

Через год после закрытия соло-проекта (React, 3×NestJS, PostgreSQL, Socket.IO, Kubernetes в GKE) я устроил себе код-ревью и нашёл 8 ошибок, которые всплыли бы при первом росте трафика: двойное списание баланса, сообщения, теряющиеся между pod'ами, чужой чат по UUID, деплой, который нельзя откатить. Почти все жили не внутри технологий, а на стыках. Разбираю каждую с кодом и исправлением.

Читать разбор 8 ошибок

От Architecture Baseline к рабочему Full Stack MVP: как не усложнить архитектуру раньше времени

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели5.1K

Architecture Baseline определяет границы системы и ключевые архитектурные решения. Но настоящая проверка начинается тогда, когда эта архитектура превращается в работающий код.

В этой статье про переход к первой Full Stack вертикали Enterprise GenAI Platform: React, ASP.NET Core, EF Core и PostgreSQL, модуль Chats, границы frontend и backend, observability, автоматические проверки и End-to-End acceptance.

Главный вопрос “как перейти от архитектурной модели к реализации, не разрушив её преждевременным усложнением”.

Читать далее

PostgreSQL 19: Коммитфест 2026-03 Часть 5.3 (DBA3, DBS)

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели6.9K

Продолжаем обзор мартовского коммитфеста 19-й версии. В третьей статье серии рассмотрим изменения, относящиеся к материалам курсов DBA3 и DBS.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2)

Часть 5.3 (DBA3, DBS) – мы здесь 🙂

Часть 5.4 (SQL, DEV1, DEV2)

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Читать далее

Сравнение провайдеров managed PostgreSQL

Время на прочтение8 мин
Охват и читатели6.1K

PostgreSQL является самой распространённой СУБД согласно исследованию StackOverflow. Но самостоятельный хостинг PostgreSQL сопряжён с риском потери данных и неоптимальной настройки.

В статье мы рассмотрим основных международных и российских провайдеров managed PostgreSQL. Их сильные и слабые стороны и сценарии оптимального использования.

Читать далее

Ближайшие события

Копия базы 1С оборвалась, а gzip -t и psql вернули 0

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели5.9K

Оборванная копия PostgreSQL может пройти gzip -t, заливку через psql и даже строгий режим с ON_ERROR_STOP: на стенде 1С все три вернули 0. Что такой обрыв всё-таки ловит, разобрано по опытам. Рядом фрагмент копии, прогнанный там же.

Какая проверка ловит оборванную копию

Я ускорил запрос в 75 раз. Через две недели оказалось, что дело было не в запросе

Время на прочтение5 мин
Охват и читатели7.8K

Добавил фильтр по городу в подзапрос — туда, куда учебники и велят его ставить. На тестовой базе в 750 строк незаметно, на проде запрос стал висеть: 0,71 с превратились в 53,7 с. Починил, замеры оставил в комментарии. Спустя две недели сел писать про это статью, перемерил — и тот же запрос на той же базе отработал за полсекунды. Разбираю, почему катастрофа рассосалась сама, почему дело было не в join и почему измеренная цифра в комментарии протухает быстрее, чем кажется.

Читать далее

PostgreSQL 19: Коммитфест 2026-03 Часть 5.2 (DBA1, DBA2)

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели6.3K

Продолжаем обзор мартовского коммитфеста 19-й версии. Во второй статье серии рассмотрим изменения, относящиеся к материалам курсов DBA1 и DBA2.

Напоминаю план статей о последнем коммитфесте 19-й версии:

Часть 5.1 (QPT)

Часть 5.2 (DBA1, DBA2) – мы здесь 🙂

Часть 5.3 (DBA3, DBS)

Часть 5.4 (SQL, DEV1, DEV2)

Об изменениях в предыдущих коммитфестах рассказано здесь: 2025-07, 2025-09, 2025-11, 2026-01.

Читать далее

Ivory v2.0.0 — за пределами Postgres

Уровень сложностиСредний
Время на прочтение4 мин
Охват и читатели4.2K

Ivory начинался как небольшой инструмент, упрощающий работу с кластерами PostgreSQL и Patroni.

Когда я начинал его делать, цель была довольно простой: иметь одно место, где можно увидеть состояние кластера, разобраться с проблемами, выполнить запросы, управлять нодами и выполнять операции Patroni, не переключаясь постоянно между браузером, терминалом, SSH-сессиями и клиентами баз данных.

Теперь Ivory помогает делать то же самое и упрощает работу с другими сложными системами баз данных: MongoDB, ClickHouse, Redis и т. д. А если вы захотите добавить любую другую базу данных, это легко сделать с помощью AI-агентов. Для этого есть специальный subagent.

Читать далее

Kafka гарантирует порядок? Разбираем 3 инцидента с Outbox

Уровень сложностиСредний
Время на прочтение22 мин
Охват и читатели5.2K

Один ключ на все события заказа — и кажется, что порядок гарантирован. А потом клиенту приходит «Ваш заказ собран» раньше, чем «Оплата получена», витрина откатывает статус назад, а после планового перезапуска одно событие пропадает навсегда.

В статье разбираем три таких инцидента из одной системы на transactional outbox, PostgreSQL и Kafka 4.2. Попробуйте сами определить, где сломалось: в источнике, в relay, в продюсере или у потребителя.

Читать далее

PostgreSQL 19: Коммитфест 2026-03 Часть 5.1 (QPT)

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели6K

Завершаем цикл статей с обзором изменений 19-й версии. Предыдущие статьи были посвящены первым четырем коммитфестам: 2025-07, 2025-09, 2025-11, 2026-01.

А сегодня начнем обзор мартовского коммитфеста 2026 года. Почему «начнем»? По опыту прошлых лет, мартовский обзор всегда очень объемный. Именно в последнем коммитфесте принимается большое число важных изменений. Обзор не только сложно подготовить, но и непросто дочитать до конца 🙂. Поэтому для 19-й версии он разбит на четыре статьи.

В первую статью вошли изменения, так или иначе связанные с оптимизацией запросов, — все, что можно отнести к нашему учебному курсу QPT. Вторая будет посвящена изменениям, которые больше относятся к курсам DBA1 и DBA2. Третья — к DBA3 и DBS. В четвертой будут рассмотрены новинки SQL, а также изменения, относящиеся к курсам DEV1 и DEV2.

Читать далее

За пределами EXPLAIN: как увидеть выполнение запроса вживую в распределённой СУБД

Время на прочтение7 мин
Охват и читатели12K

Представьте, что ваш запрос в Greenplum внезапно завис. Есть план выполнения, но что именно сейчас происходит, непонятно. Перекос данных? Spill на диск? В итоге вы перезапускаете запрос наугад: инструментов для живого наблюдения попросту нет. 

Всем привет! Я Алексей Рожок, разработчик ClickHouse в Yandex Cloud. Летом 2026 года я стажировался в Greenplum/Cloudberry и реализовывал проект, который помогает увидеть весь путь запроса. В статье покажу, как достучаться до процессов на всех хостах кластера и почему сбор метрик пришлось вынести с координатора в отдельный сервис YAGPCC. 

Читать далее
1
23 ...