PostgreSQL *

Бывают ошибки, которые не видит ни ревью, ни тесты: код отрабатывает правильно, прогон зелёный, а запросов к базе он делает в сто раз больше прежнего. Я убрал из фонового планировщика классический N+1 — самым что ни на есть учебным способом — и чуть не выкатил в прод версию, где нагрузка росла как квадрат числа пользователей. Разбираемся с замерами в руках: при чём тут expire_on_commit, почему предзагрузка пачкой сама по себе ни в чём не виновата и как одна строка превращает цикл в N².

Я делаю сервис онлайн-записи для салонов красоты: клиент записывается в чат-боте или на странице, а запись падает в расписание мастера. Однажды мастер написал мне: на 15:00 к ней пришли два клиента. Оба записаны, оба уверены, что слот их. Классическая двойная бронь — и классическая race condition. Разберу, почему наивная проверка «свободно ли время?» не спасает, и как мы закрыли дыру двумя слоями: advisory-lock и EXCLUDE-констрейнтом в PostgreSQL. По пути — один неочевидный подвох с IMMUTABLE, на который легко напороться.

При переносе большой системы разработанной под одну СУБД на другую неизбежно возникают различные "нюансы", то что эффективно работало в одной СУБД, уже не так эффективно (или совсем неэффективно) работает в другой.

В частности SQL разработанный под Oracle при всей синтаксической схожести может работать совсем не так в PostgreSQL Однако, это не значит, что ничего нельзя сделать, зачастую, если переписать код, используя особенности "новой" СУБД вы можете получить ту же эффективность выполнения.

Сегодня я хочу рассмотреть один частный случай, связанный с обработкой аналитических(оконных) функций оптимизаторами Postgres и Oracle.

Итак на герой, рассмотрим на синтетическом примере (который довольно похож на реальный)
создаём табличку t_rownum_stop c составным первичным ключом (obj_id - селективное, но не уникальное поле, key_1 и cat_id малоселективные поля)

Что получится, если собрать PostgreSQL, Airflow, JupyterLab, MinIO, Superset, шесть MCP-сервисов и локальную модель Ollama в одном Docker Compose-стенде?

Показываю полный путь синтетических промышленных данных: от витрин и проверок качества до Parquet-артефактов, MCP-инструментов и LLM-пояснений. Внутри — архитектура, воспроизводимый запуск, результаты проверок и открытый репозиторий.

pgrust это СУБД или злая шутка?

Майкл Мэйлис (Michael Malis), житель Сан Франциско, основатель freshpaint‑io, работал в компании Heap — человек в мире Postgres не слишком известный, хотя давний пользователь. Он, скорее, из мира фанатов Rust и Common LISP. Он был бы возмутителем спокойствия Postgres‑сообщества — да чего там: ИТ‑сообщества — если б там сейчас было какое‑то спокойствие.

У него есть свой сайт — malisper.me. Там многое рассказано, хотя наиболее шустро новость разошлась с форумов — с рэддит: pgrust: Postgres rewritten from scratch in Rust, currently passing 34% of the Postgres test suite, или с ycombinator: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests. В рунете новость появилась на OpenNET.ru: pgrust — клон PostgreSQL на Rust, проходящий все регрессионные тесты.

Если CREATE INDEX CONCURRENTLY или REINDEX INDEX CONCURRENTLY завершается с ошибкой, Postgres оставляет после себя невалидный индекс. Многие инженеры считают такие индексы безобидными заготовками, которые просто ждут удаления. В конце концов, планировщик ведь не использует их в запросах, верно?

Нет. Невалидные индексы совсем не безобидны. Они продолжают потреблять ресурсы, генерировать ввод‑вывод, мешать оптимизациям и даже создавать конкуренцию за блокировки — при этом не давая никакого выигрыша в производительности запросов.

В этой статье мы на реальных примерах рассмотрим скрытые издержки невалидных индексов, о которых должен знать каждый администратор Postgres.

Когда приходишь на аудит СУБД к разным компаниям, картина удивительно похожа: одни и те же проблемы, одни и те же причины. Меня зовут Андрей, я DBA в группе поддержки системного ПО Центра экспертизы по комплексному сервису К2Тех, сертифицированный эксперт Postgres Pro. В этой статье представлен ТОП-10 ошибок, с которыми мы встречаемся чаще всего. Я разберу, чем они опасны, почему возникают, и как их можно решить. Скорее всего, многие пункты покажутся вам до боли знакомыми:

Многие статьи на тему секционирования заканчиваются "и теперь у вас есть партиции". А что дальше - когда нужно обновить данные или отсоединить секцию?

Хабр, привет!

В эфире -  команда из центра компетенций VMware. Недавно мы разбирали  интересное поведение в работе ПО у одного из наших заказчиков — облачного провайдера.

 Вы знали, что в vCloud Director с NSX‑V добавление новой внешней сети на шлюз может тихо отключить уже существующую? Система предательски завершит задачу без ошибок, а заказчик заметит пропажу только по упавшим ВМ. Мы воспроизвели это в тестовом контуре и проследили всю цепочку — от галочек в интерфейсе до delete-запроса в PostgreSQL.

Статья — для тех, кто сопровождает vCD с NSX‑V в продакшне. Если вы хоть раз правили внешние сети через UI, вы в группе риска. Покажем, как именно это происходит, и дадим два рабочих обхода — без танцев с БД и перехода на NSX‑T.

Сразу отвечаю на вопрос, который вы задали бы в первом же комментарии: а почему не pgvector?

Короткий ответ: ровно то, что pgvector делает хорошо — генерацию кандидатов (найти top‑k ближайших по косинусу) — мы и советуем отдавать pgvector, если он у вас есть. Свой ANN мы написали, потому что (1) pgvector есть не везде, где должна работать наша память, и (2) самое ценное в нашей задаче — вообще не генерация кандидатов. Про это вся статья, так что давайте по порядку.

Однажды я решил проверить на практике байку, которую слышал на десятке собеседований: “у нас на проде было такое-то место продано дважды, потому что…”. Оказалось, воспроизвести это не просто легко — это воспроизводится настолько надёжно и настолько наглядно, что грех было не довести дело до конца: взять систему бронирования мест, специально сломать её, замерить, насколько плохо, а потом последовательно починить тремя разными способами — и честно сравнить, что каждый из них стоит по производительности.

Спойлер: один из результатов оказался прямо противоположным тому, что я ожидал увидеть.

Данные тоже стареют. Им, конечно, не всегда нужен вечный покой — чаще достаточно переехать туда, где они будут занимать меньше места, стоить дешевле в хранении и не мешать тем, кто продолжает работать. В Tantor Postgres эта задача решается не набором разрозненных скриптов, а полноценной системой управления жизненным циклом данных: с регулярным сбором статистики, анализом реальной активности, объяснимыми рекомендациями, аудитом, dry-run и безопасным поэтапным переносом объектов между уровнями хранения. В этой статье мы разберем полный операторский сценарий работы с ILM (information lifecycle management) от появления первых рекомендаций до их безопасного исполнения.

Dasha - opensource дашборд производительности PostgreSQL. Читает состояние кластеров из системных представлений, без агентов на хостах; поддерживает версии 14–18 и работу с несколькими кластерами в одном интерфейсе. Анализ запросов и снимки pg_stat_statements со сравнением и авто-снимками по триггерам, анализ индексов и таблиц с учётом всех хостов кластера, обслуживание и блокировки, диагностика конфигурации, композитная оценка Health Score, поиск по логам managed-кластеров Yandex Cloud. В комплекте - read-only MCP-коннектор для AI-ассистентов.

В статье - краткий обзор и скриншоты возможностей по разделам.

Зашёл тут на карту и вижу странную картину. На Чистых прудах висят три пина ровно друг на друге. Тыкаю, а там один и тот же «Вишнёвый сад» в Ленкоме. Совпадает всё, вплоть до времени и зала. Просто данные прилетели из трёх разных мест. Где-то площадка записана просто как Ленком, где-то полностью с именем Марка Захарова, а в третьем случае вообще пусто. Для пользователя это три разных события на карте, хотя спектакль на самом деле один.

У меня сейчас Окрест тянет афиши по шестнадцати городам из Яндекс Афиши, Afisha.ru, Timepad, KudaGo и телеграм-каналов самих площадок. Сейчас в базе 23 097 активных событий, и пересечений между источниками много. 8260 событий приходят из двух источников, 533 из трёх, десять встречаются сразу в четырёх. На карте всё это должно превращаться в одну точку, а не в гирлянду пинов.

10 лет в .NET, отпуск в Альпах и pgAdmin, который меня достал.

Начало июля, горный воздух, а в голове рабочая фрустрация. Ну сколько можно ждать по 30 секунд, пока pgAdmin разродится ради одного короткого запроса? Из инструментов с собой только смартфон и лимиты Claude Code. Challenge accepted.

За выходные, целиком с телефона, не написав руками ни единой строчки кода, я собрал первую рабочую версию нативного GUI для PostgreSQL. Дальше две недели вечернего кодинга, 17 релизов, и проект уже в Microsoft Store.

Встречайте: NativeAOT, взлетает за ~100 мс, весит всего 19 МБ, ноль трекеров, лицензия MIT.

Написал об этом подробный пост. Без лишней воды и успешного успеха рассказываю: как агент тащил разработку (от кода до дебага в песочнице) и где ему всё-таки нужна была менторская рука, какие грабли подкинул NativeAOT и как бесплатно выкатиться в Microsoft Store без покупки дорогого Authenticode-сертификата.

Заходите почитать, а в конце проголосуйте в опросе, какую фичу пилить следующей: ER-диаграммы, визуальный дифф EXPLAIN, UI для бэкапов или локальный AI?

Есть таблица GPS-точек. Транспорт шлёт координаты каждые несколько секунд, за сутки набегают миллионы строк, и таблица секционирована по времени. Значит, кто-то должен заранее создавать партицию на завтра и отцеплять партиции старше девяноста дней. Иначе в одну прекрасную ночь вставка упадёт с no partition of relation "gps_points" found for row, и это будет ровно в тот момент, когда никто не смотрит.

Перед командой, выросшей на MySQL/MariaDB, встаёт вопрос перехода на PostgreSQL: лицензии, экосистема расширений, более предсказуемое поведение при конкурентных нагрузках - причин достаточно. Проблема в другом: как перенести боевую базу, которая не останавливается ни на минуту, без часов простоя и без риска потерять данные, записанные во время переноса.

В этой статье - как мы решали эту задачу для интернет-магазина на MariaDB, почему готовые консольные конвертеры не годятся для «живой» миграции, и как выглядит рабочая схема на Debezium + Kafka Connect, включая Ansible-роль для повторяемого запуска.

У каждого релиза Postgres свой характер.

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

В Postgres 19 есть улучшения на любой вкус. Встроенная команда REPACK CONCURRENTLY упрощает обслуживание крупных рабочих баз данных. SQL-запросы к графам свойств наверняка привлекут много внимания. Логическая репликация становится полноценнее.

Разработчики также улучшили VACUUM, EXPLAIN, COPY, секционирование, мониторинг и планировщик. Эти изменения не так заметны, но упрощают эксплуатацию рабочих систем.

До финального релиза детали могут измениться. Но бета-версия Postgres 19 уже позволяет оценить новые возможности и понять, как они повлияют на разработку и эксплуатацию систем.

18–21 ноября 2026 года в Непале пройдёт PGConf.Nepal 2026 — четвёртая PostgreSQL-конференция в стране. Предыдущие конференции состоялись в 2018, 2023 и в 2025 годах. В этом году конференция должна стать шире по составу участников, организаций и стран.

Этот материал подготовил автор решения Database Compression Tool (DCT), представленного на Инфостарт Маркетплейс. Мы публикуем его от имени компании, чтобы поделиться практической экспертизой наших авторов. В статье разработчик DCT рассказывает, как устроена свертка больших баз 1С, какие ошибки могут привести к нарушению учета и что необходимо учитывать при работе с базами объемом в сотни гигабайт и несколько терабайт. Мнение, выводы и практические рекомендации в материале принадлежат автору решения.

Заявка выглядит буднично: ERP размером 2,3 терабайта, бэкап перестал влезать в ночное окно, место в СХД заканчивается быстрее, чем согласовывается его закупка. Диски можно докупать до бесконечности, но в какой-то момент кто-то произносит слово «свёртка». И тут выясняется, что удалить из работающей учётной системы две трети строк и ничего при этом не сломать заметно сложнее, чем звучит.