Если вы администрируете Postgres Pro Enterprise и ваша инфраструктура охватывает несколько дата-центров, вы наверняка сталкивались с одной и той же проблемой: репликация начинает «есть» межцодовый канал и нагружать основной сервер. В новой версии BiHA появилось решение — каскадная репликация. Рассказываем, как она работает и когда стоит использовать её.
Вы когда-нибудь получали два списания с карты за одну покупку? Или видели дважды созданный заказ после одного клика? Это не баг платёжной системы - это баг вашего кода. Имя этому баг - отсутствие идемпотентности.
На разных континентах и субконтинентах
В расписании конференции PGConf.Russia, к которой мы ещё, конечно, вернёмся в разделе Конференции, моё внимание привлёк вот такой доклад:
YMatrix Domino: Design Considerations, Trade-offs, and Implementation of In-Database Stream Processing - видимо, игрек впереди названия как раз в честь Яо Яндуна (Yandong Yao), гендира и сооснователя компании Ymatrix (также известной как Beijing Siwei Zongheng Data Technology Co., Ltd. или «Сывэй Цзунхэн»). Не думаю, что многим читателям этих обзоров она известна хотя бы по одному из этих названий.
Он экс-руководитель пекинского R&D-центра Greenplum.
Оказывается, на хабре есть статья о YMatrix:
Прошла 5 ежегодная конференция PG BootСamp Russia 2026. В этот раз она проходила в Москве 19 марта 2026 года. 563 оффлайн участника и порядка 1300 онлайн. Первая конференция прошла в 2023 году и дальше проводилась в разных городах. В статье - репортаж с конференции и краткий обзор докладов
Если API начинает тормозить, первое решение обычно очевидно — добавить Redis. Но иногда оказывается, что проблема гораздо проще. В одном из сервисов PostgreSQL начал упираться в повторяющиеся запросы. Одни и те же данные запрашивались тысячами клиентов. Практически каждый HTTP-запрос заканчивался одинаковым SQL-запросом. Любопытство победило — вместо готового решения был написан небольшой кэш прямо внутри сервиса. На это ушло примерно полчаса. Результат оказался неожиданным: некоторые эндпоинты ускорились почти в 7 раз. Вот, почему это произошло и как работает такая схема.
Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:
• API отвечало слишком долго
• CPU базы был загружен почти на 100%
GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL
GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL
Глоссарий терминов | Postgres DBA | Дзен
Может ли ИИ заменить эксперта по PostgreSQL?
С учетом существующих точек зрения о потенциале полного замещения человека искусственным интеллектом в задачах оптимизации баз данных, в данном исследовании проведен анализ работы нейросетевой модели DeepSeek при оценке производительности СУБД PostgreSQL с применением статистического метода «majority vote» на выборках из пяти и одиннадцати независимых прогонов. Результаты подтверждают, что даже при эффективном выявлении закономерностей и диагностике узких мест с помощью ИИ, окончательная интерпретация выводов остается прерогативой специалиста, что позиционирует нейросеть не как замену эксперту, а как инструмент для фильтрации случайных ошибок и оптимизации рутинных процессов.
Я перепробовал несколько способов вести документацию по базе данных — и у каждого были свои проблемы: информации недостаточно, сложно поддерживать, непонятна команде. Хуже всего, что плохая документация по БД тянет за собой проблемы с требованиями к данным — а это не только таблицы, но и миграции, и данные в коде. В какой-то момент я понял, что пытался решить одним документом три разные задачи.
Всем привет!
В этой статье мы рассмотрим микросервис для управления файлами 3D туров по музеям, написанный на Go. Будет представлен код сервиса, который выполняет набор некоторых манипуляций с zip архивам, в том числе основную задачу, а именно распаковку и загрузку их в S3 хранилище.
VACUUM в PostgreSQL принято считать универсальным средством поддержания порядка: он очищает мёртвые кортежи, обновляет статистику и вроде бы держит базу «в форме». Но с индексами всё сложнее. В какой-то момент они начинают расти и деградировать так, что это уже влияет на планы запросов и поведение оптимизатора — при том, что формально всё обслуживается корректно.
Разберёмся, где именно возникает это расхождение между ожиданиями и реальностью и что на самом деле происходит внутри B-дерева.
Распараллеливаем процесс вставки данных в PostgreSQL при помощи Spring с сохранением атомарности всей операции
Разработчики часто сталкиваются с проблемами производительности своих систем. Один из привычных способов ускорить медленный бизнес-процесс — распараллелить его. Это почти всегда работает: чем больше потоков обслуживают задачу, тем быстрее она выполняется.
Но когда речь заходит о вставке данных в PostgreSQL, возникает проблема: распараллеливание действительно ускоряет операцию, но ломает ее атомарность. Данные начинают появляться в таблице частями. Для многих бизнес-процессов это неприемлемо — нужно, чтобы вся пачка данных становилась доступной одновременно.
В этой статье расскажу о том, как сделать вставку данных одновременно многопоточной и атомарной.
С вами снова Виталий Виноградов, я занимаюсь созданием asapBI - платформы для моделирования баз данных и ETL.
Продолжу цикл по системе.
Чего хочется от ETL процесса?
Если процесс простой – например, проброс данных из одной таблицы в другую с промежуточным расчетом – то графический мэппинг полей. Таких простых пробросов в работе – 90%, не хочется лазить по SQL-коду.
Если же процесс сложный – только тогда уже в бой идет ручной SQL, Python, Java, Scala, R.
Если процесс длительный – тогда его лучше выполнять на внешних кластерах Trino, Spark, Impala – как говорится, хранилища отдельно, считалища – отдельно.
Еще нужна только одна точка контроля загрузок – не дело, когда мониторинг загрузок раскидан по разным системам.
В связи с последними (?) событиями было бы здорово иметь возможность заниматься разработкой в оффлайне – сидишь в палатке без 5G, разрабатываешь модели и тестируешь трансформации и цепочки без доступа к инету, а вечером результат сбрасываешь в систему разработки через wi-fi придорожного кафе.
Причем должна быть возможность убрать asapBI и продолжать заниматься разработкой вручную (= медленно и печально) – этим мы предотвращаем вендор лок.
Как бы нам это все замиксовать?
На текущий момент существует много систем со своими интерфейсами и для моделей данных, ETL–процессов нужно в них создавать объекты. Объектов много, надо не забывать, где что лежит и как завязано.
По идее, хорошо бы иметь единый интерфейс, где объекты, рассыпанные по разным системам, связаны между собой. Если убрать этот интерфейс, то модели данных и ETL процессы не рассыплются, все продолжит работу, но настраивать будет уже не так удобно. Единый интерфейс просто объединяет в себе удобную работу с разными инструментами. Именно этот принцип я и реализую в asapBI.
Когда читаешь новости про очередную миллиардную сделку (типа покупки Neon за $1 млрд), невольно задумываешься: а что такого ценного в этих базах данных? Вроде же есть PostgreSQL, MySQL - бесплатно, open source. Но нет, люди платят, и платят огромные деньги. Чтобы понять, за что, нужно заглянуть под капот. И начать не с распределённых монстров, а с самого простого - с одной-единственной ноды.
В какой-то момент я понял неприятную вещь: если твой канал связи живет по чужому настроению, политической погоде, сбою в чужом облаке или очередной внезапной любви регулятора к кнопке «запретить» — это не твой канал связи. Это аренда с правом внезапного выселения.
Мне эта модель быстро наскучила.
Поэтому я сделал то, что обычно делают люди с нездоровой смесью инженерной паранойи, скуки и профессиональной деформации: психанул и начал писать свой мессенджер.
Привет, ХАБР! Я Владимир Хаймин, эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга?
Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня, прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.
TL;DR
Мигрировал продакшн базу с Supabase на VPS PostgreSQL прямо на работающем проекте — без остановки, без потери данных. Заодно перенёс авторизацию через strangler-подход и убрал Supabase из SSR read-path. Расскажу три инженерных решения с кодом.
Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.
Это текстовая версия доклада с Java Rock Star Meetup, с которым выступал Дмитрий Фатов (@FatOFF ) — руководитель разработки Газпромбанка с опытом разработки приложений более 13 лет. Дмитрий работал как backend-, так и fullstack-разработчиком на языках Java, Kotlin, JS, TS, 1С и имеет большой опыт работы с SQL-базами данных.
Проблема N+1 стара как мир. Инструментов много: Debugbar хорош локально, Telescope тяжеловат для продакшена. Мне хотелось решения, которое будет «стучать» в Slack или Telegram именно тогда, когда проблема случилась на проде, и при этом сразу показывать пальцем на виновную строку кода.
Привет, Хабр! Я люблю слушать книги, но не все есть на Литрес и Storytel. Особенно это касается профессиональной литературы, фанфиков, статей и документов — всего того, что вряд ли когда-нибудь озвучат профессиональные дикторы.
Я поняла, что нейросетевые голоса уже достаточно хороши для комфортного прослушивания. И подумала: а что если сделать Telegram-бота, которому можно просто скинуть файл — а через пару минут слушать аудиокнигу в удобном плеере прямо в Telegram?
Так родился VoiceBooks — open-source сервис для озвучки книг, который работает полностью бесплатно.
В этой статье я разберу архитектуру open-source проекта: как организован парсинг 6 форматов в единый пайплайн, как работает фоновая генерация аудио без Celery и RabbitMQ, и как элегантно обойти лимиты Telegram Bot API на загрузку файлов.
Стек: Python 3.12, FastAPI, aiogram 3, Edge TTS, SQLAlchemy 2.0 + PostgreSQL. Деплой — Railway.
