PostgreSQL *

Продолжаем цикл статей с обзором изменений 19 версии. Сегодня о ноябрьском коммитфесте 2025 года.

Самое интересное из предыдущих коммитфестов можно прочитать здесь: 2025-07, 2025-09.

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



Привет! Мы – Дмитрий Харлан и Антон Ляшедько, представители команды развития системы бизнес-планирования ВТБ.

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

На связи команда внутренних инновационных сервисов ecom.tech.  

Мы занимаемся разработкой продуктов для внутренних нужд компании, экспериментируем с внутренними AI-продуктами для сотрудников: от забавных и полезных ботов до автоматизации повседневных задач. Сегодня мы расскажем, как помогли разгрузить аналитиков от их типовых задач с помощью искусственного интеллекта – внутри реальные кейсы, гайды и пошаговые инструкции на примере ecom.tech. Поехали!

Мы уже писали о нагрузочном тестировании машины баз данных Tantor XData 2Y на базе процессоров Intel, точнее, об успешно пройденном тесте на 30 тыс. пользователей 1С. Впечатляющие показатели — это прекрасно, однако реальность рынка enterprise-решений такова, что технические характеристики — не единственный критерий для выбора оборудования. Требования 398-ФЗ, стратегии импортозамещения, санкционные риски и бюджетные ограничения заставляют компании искать баланс между производительностью и другими факторами. 

В линейке Tantor XData есть модель 2B на базе процессоров Baikal-S, позиционируемая как ответ на подобные вызовы. В новой статье мы делимся результатами нагрузочного тестирования этой модели и рассказываем об особенностях работы ARM-архитектуры с PostgreSQL и практическом опыте оптимизации такой системы — со всеми техническими деталями, метриками производительности и найденными узкими местами.

Третья статья цикла о построении CDC-пайплайна с нуля. Сегодня — самое интересное: захватываем изменения из PostgreSQL и отправляем в Kafka. И разбираемся, почему WAL может съесть весь диск, даже если данные не меняются.

Продолжаю рубрику «Мысли вслух». Цель данной публикации – описать алгоритмы и новизну моих исследований по созданию кластера СУБД с горизонтальным масштабированием производительности – распределенного вычислительного кластера (РВК). Набралась очередная порция материалов в следствие новых изысканий и натурных экспериментов, которыми и делюсь. Сегодня речь пойдет о возможных протоколах работы РВК. Создание распределённого кластера СУБД обычно приносит серьёзные потери в производительности одиночных операций, плюс сложности в разработке, эксплуатации и сопровождении. Цель моей работы – создать РВК без этих недостатков.

Выделили из production-проекта и открыли в open-source PWA-приложение для персонального фитнес-тренера с AI.

Дисклеймер: это open source, в нем могут быть недостатки, заходите, предлагайте идеи, исправления. Публикую тут в ознакомительных и образовательных целях. Выпилил этот кусок в open source из части личного проекта, о котором писал тут. Весь код писал полностью Claude Code на Opus 4.5 с thinking режимом.

Как известно, компания OpenAI, создавшая ChatGPT, находится на переднем крае развития ИИ и многим небезинтересно, какие технологии и решения работают "под капотом" этой популярной компании. Сотрудник технического отдела OpenAI, Бохан Чжан (Bohan Zhang) приоткрыл небольшую завесу о том, как компания работает с базами данных и с какими вызовами им приходиться сталкиваться и как их приходиться преодолевать. Это статья является вольным переводом оригинальной статьи Scaling PostgreSQL to power 800 million ChatGPT users, опубликованной на официальном сайте OpenAI, с некоторыми пояснениями и умозаключениями от переводчика, с учетом его знаний и опыта.

«Страница заказов грузится вечность», — такой тикет прилетел в понедельник утром. На проде 800 тысяч записей, а типичный запрос с фильтрацией и сортировкой заставлял менеджеров ждать по 12 секунд. В этой статье разберем, почему стандартный индекс по одному полю не сработал, как EXPLAIN ANALYZE помог найти «бутылочное горлышко» и почему порядок полей в составном индексе имеет решающее значение

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

В предыдущей статье мы рассказали, как установить Digital Q.DataBase на Astra Linux 1.8 и начать работу с этой российской СУБД, которая поддерживает нативную работу с диалектами MS SQL, PostgreSQL и Oracle. Сегодня мы поговорим о том, как перенести уже существующие данные в Digital Q.DataBase из других систем управления базами данных. 

Для решения поставленной задачи мы разработали инструмент – Мастер переноса БД. Он позволяет выгрузить структуру, данные и хранимую логику из уже развернутой БД на одной из трех СУБД (Oraсle, MS SQL и PostgreSQL) и загрузить их в Digital Q.DataBase без переписывания кода приложений в отличие от любых миграторов-конверторов.

Оконные функции в SQL выглядят безобидно ровно до того момента, пока не попадают на реальные объёмы данных. В этой статье разбирается конкретный аналитический запрос в PostgreSQL: от формулировки задачи и использования lead() до детального анализа плана выполнения с EXPLAIN ANALYZE. Без абстракций и «магии оптимизатора» — только факты, цифры, сортировки на диск, буферы и выводы, которые полезно уметь делать любому аналитику, работающему с большими таблицами.

В системах, где генерируются миллионы событий в день (например логи), первичные ключи часто строятся на основе UUID. Это логично: они глобально уникальны, не требуют централизованного генератора и хорошо масштабируются.

Но не все UUID одинаково полезны. Особенно когда речь заходит о производительности БД.

В нашем сервисе мониторинга и анализа PostgreSQL мы использовали UUID v1 - и столкнулись с ростом дисковой нагрузки на PostgreSQL. После перехода на UUID v7 удалось добиться сокращения числа операций с диском в 2 раза, на четверть снизить размеры индексов и полностью устранить их фрагментацию.

В первой части было разобрано, как настроить RLS в Go, почему is_local=true спасает от утечек в PgBouncer, и как покрыть это интеграционными тестами. Если вы еще не настроили базовую изоляцию, начните оттуда.

Сегодня мы пойдем глубже. Мы не будем говорить о синтаксисе. Мы поговорим об архитектуре. О том, почему RLS - это не просто "удобный фильтр", а нативный механизм инкапсуляции, который решает проблемы распределенных систем и рисков безопасности прямо в слое данных, не раздувая Ops-сложность до сотен схем и баз.

Кому и зачем читать?

Junior/Middle: Поймете, почему RLS - это архитектурный выбор, а не просто WHERE tenant_id = ?. Узнаете про TOCTOU и как его избежать.

Senior/Architect: Увидите паттерны для highload (партиционирование + RLS) и production-грабли (матвьюхи, репликация).

Запрос выполняется за 25 мс, но планируется 500 мс. База небольшая, в запросе 9 таблиц, default_statistics_target всего 500. Откуда такой разрыв?
Недавно в pgsql-performance поступил именно такой кейс. Разбор показал неожиданного виновника: статистика по колонкам таблиц в pg_statistic.

Несколько месяцев назад я опубликовал статью про использование Outline для корпоративной базы знаний. Теперь хочу описать некоторые процессы подробнее.

Сегодня речь пойдет про основы создания такой базы знаний. Опишу кратко применение метода Event Storming, ревью структуры, регламент по ведению БЗ.

Базы данных давно являются фундаментом цифровой экономики. От их архитектуры и производительности во многом зависят скорость вывода продуктов на рынок, стабильность сервисов и итоговая стоимость ИТ-инфраструктуры. В мировой практике одним из основных стандартов де-факто, вокруг которого формируются экосистемы серьезных решений, стала открытая СУБД PostgreSQL. В России она используется во множестве корпоративных приложений, есть целый ряд отечественных форков и дистрибутивов. Но у ряда зарубежных компаний( есть серьезные прорывные реализации, интенсивно развивающие Postgres (например, Aurora, AlloyDB и Neon, об этом ниже), а у российских этого почему-то не наблюдается. Это противоречие между массовым использованием PostgreSQL в нашей стране и отсутствием технологического прорыва задает остроту сегодняшней повестки отечественного СУБД-строения.

В статье рассматриваются текущие возможности горизонтального масштабирования СУБД для 1С, а также какое решение предлагает Tantor Postgres.

За 8 дней частичной занятости я собрал RAG-систему на NestJS + PostgreSQL (pgvector), которая обрабатывает ~11 000 чанков документов.

Первая версия отвечала около 4 минут, после оптимизации - 40–60 секунд.

Главный вывод: RAG - это не «векторный поиск + LLM», а в первую очередь подготовка данных, фильтрация контекста и аккуратная работа с промптами.

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

Всем привет, меня зовут Алексей Леонтьев, я техлид и архитектор на проекте Smartbot в компании KTS. Smartbot — это nocode-платформа для настройки сценариев чат-ботов, которые могут работать в нескольких соцсетях и мессенджерах одновременно.

Мы храним много данных о событиях, которые обрабатывает наша платформа. Раньше для этого мы использовали Postgres. Но возникла задача сократить потребляемые кластером ресурсы.

В этой статье я расскажу о том, как мы бесшовно перенесли данные из Postgres в ClickHouse. И при этом сократили оперативную память в 4 раза, а размер потребляемого дискового пространства — на порядок.