PostgreSQL *

Если API начинает тормозить, первое решение обычно очевидно — добавить Redis. Но иногда оказывается, что проблема гораздо проще. В одном из сервисов PostgreSQL начал упираться в повторяющиеся запросы. Одни и те же данные запрашивались тысячами клиентов. Практически каждый HTTP-запрос заканчивался одинаковым SQL-запросом. Любопытство победило — вместо готового решения был написан небольшой кэш прямо внутри сервиса. На это ушло примерно полчаса. Результат оказался неожиданным: некоторые эндпоинты ускорились почти в 7 раз. Вот, почему это произошло и как работает такая схема.

Достаточно большое количество проблем производительности в backend-приложениях на самом деле находятся не в коде. За последние пару лет мне несколько раз приходилось разбирать системы, где:

• API отвечало слишком долго

• CPU базы был загружен почти на 100%

Telegram: @pg_expecto

MAX: PG_EXPECTO

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.

Мы продолжаем серию интервью с разработчиками Postgres Professional, которые получили медали за вклад в ванильный PostgreSQL. Почему полезен даже не принятый сообществом патч и при чём здесь везение, сегодня расскажет Александр Пыхалов.

Почему SUM() OVER (ORDER BY ...) иногда даёт неожиданный результат, даже когда запрос синтаксически правильный? В статье на практических примерах разбираю, как работают оконные фреймы в SQL, чем отличаются ROWS, RANGE и GROUPS, где чаще всего возникает путаница и как писать накопительные итоги и скользящие метрики без сюрпризов. Если используете оконные функции в аналитике, этот разбор поможет сделать их поведение предсказуемым и управляемым.

Telegram: @pg_expecto

MAX: PG_EXPECTO

GitHub - Комплекс pg_expecto для статистического анализа производительности и нагрузочного тестирования СУБД PostgreSQL

GitFlic - pg_expecto - статистический анализ производительности и ожиданий СУБД PostgreSQL

Глоссарий терминов | Postgres DBA | Дзен

Процесс начальной конфигурации сервера PostgreSQL, как правило, опирается на использование автоматизированных генераторов параметров (конфигураторов). Такие инструменты, включая широко применяемый конфигуратор компании «Тантор Лабс», предлагают готовый набор настроек на основе ограниченных входных данных — объёма оперативной памяти, количества ядер CPU и предполагаемого типа нагрузки. Однако на практике сгенерир��ванная таким образом конфигурация не учитывает специфику реального рабочего профиля и особенности взаимодействия СУБД с аппаратным обеспечением, что может приводить к критическому снижению производительности, росту I/O wait и неэффективному использованию ресурсов.

Возникает закономерный вопрос: возможно ли выявить и устранить эти «узкие места» без модернизации оборудования, опираясь лишь на углублённый анализ статистических данных?

При обновлении PostgreSQL с 17-й на 18-ю версию часть пользователей при работе с временными таблицами столкнулась с неожиданной ошибкой no empty local buffer available, в том числе, в типовых конфигурациях 1С. В статье разбираем первопричину: как новый механизм асинхронного prefetch в read stream конкурирует с insert stream за слоты local buffer pool, почему это не проявлялось в PostgreSQL 17, и какие исправления предложила сообществу PostgreSQL команда Tantor.