PostgreSQL *

Если ваш сервис одновременно пишет в БД и дёргает внешние API, прямо сейчас у вас есть как минимум один из этих сценариев:

– деньги списаны, заказа в базе нет;
– товар на складе заблокирован навсегда под «призрачный» заказ;
– курьерская служба везёт посылку, которую никто не заказывал.

Это не баги в коде – это архитектурная проблема двойной записи. И у неё есть классическое решение: паттерны Transactional Outbox, Result Table и Saga Compensation. Под катом – не только теория, но и живой рабочий проект на Scala, который можно склонировать и запустить.

Представьте: пользователь добавляет одного сотрудника в группу где‑то в глубине иерархии — и сидит, смотрит на крутящийся лоадер почти минуту. А запрос «покажи всех участников этой группы» отрабатывает так долго, что проще сходить за кофе. Стоит иерархии стать чуть глубже — база и вовсе падает по тайм‑ауту. Именно так вела себя наша старая схема хранения оргструктуры, когда бизнес пришёл с новыми аппетитами: сотни тысяч человек в одной группе и вложенность втрое больше, чем та, на которую всё проектировалось.

Так выглядела наша точка отсчёта. Речь о Директории — компоненте B2B‑платформы Яндекс 360, который отвечает за жизненный цикл организаций и служит единым источником истины об их оргструктуре для других сервисов: Календаря, Почты, Мессенджера, Диска. Когда вы ставите встречу на целый отдел или отправляете общую рассылку для бухгалтерии, под капотом к Директории прилетает запрос «Дай мне всех пользователей этой группы с учётом всей вложенности». Это наш самый горячий запрос, и старая архитектура с ним перестала справляться.

Привет! Меня зовут Малик, я занимаюсь развитием B2B‑платформы в Яндекс 360. В этой статье я расскажу, зачем нам вообще понадобился граф при хранении оргструктур, почему мы решили засунуть этот граф именно в PostgreSQL и как мы это реализовали. А ещё — как нам удалось выкатить такое масштабное архитектурное изменение в продакшен без даунтаймов и что мы получили в итоге.

От CRUD на FastAPI до видеоплатформы: история одного pet-проекта

История о том, как учебный CRUD-проект на FastAPI постепенно превратился в стенд с микросервисами, мониторингом, Kubernetes.

ILM (управление жизненным циклом данных) в Tantor Postgres 18 работает в три этапа: администратор задаёт правила, система собирает статистику и выдаёт рекомендации, а вот что делать дальше - решение за администратором. В туториале я последовательно прохожу все эти этапы: установка расширений, настройка tablespace'ов, работа с обычными и секционированными таблицами и проверка рекомендаций через Flamegraph. В общем, разбираю новый функционал с практической стороны.

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

Меня зовут Жуйков Андрей, в Диасофт я занимаюсь развитием и продвижением СУБД Digital Q.DataBase.

Импортозамещение СУБД перешло из разряда регуляторных требований в практическую плоскость: компаниям нужно менять платформы без остановки бизнеса. Типичная проблема — огромная экосистема вокруг MS SQL, PostgreSQL или Oracle с тысячами процедур, отчетов и интеграций. Ручной перенос такого объема (например, 900 тысяч строк кода) занимает месяцы и несет риски, при этом даже автоматизация не исключает доработок.

Даже с автоматизированными средствами конвертации большинство проектов миграции СУБД требует доработок и тестирования, поэтому ключевым требованием становится сохранение существующей логики приложений. Digital Q.DataBase решает эту задачу через воспроизведение функциональности популярных СУБД и поддержку их диалектов SQL, что позволяет переносить системы быстрее без масштабной переработки прикладного слоя.

В новой версии Digital Q.DataBase существенно переработана архитектура продукта. Вместо единого монолитного решения СУБД получила независимые модули, воспроизводящие функциональность PostgreSQL, Microsoft SQL Server и Oracle Database. Это упрощает установку, сопровождение и обновление системы, а также позволяет использовать только те компоненты, которые действительно необходимы в конкретном проекте.

В этой статье покажу, как установить Digital Q.DataBase 18.2 на Astra Linux 1.8, познакомлю с новой архитектурой продукта и продемонстрирую подключение к каждому из поддерживаемых диалектов.

Какое-то время назад у меня возник инцидент с IOPS в продакшене (я уже писал о нём). Однако у меня не было никакой возможности замерить происходившее. Так как EBS скрывает от меня все механизмы, я решил замерить поведение того запроса в контролируемой мной среде. План такой: я выполняю один и тот же запрос трижды, каждый раз замеряя показания (сначала со страницами в общих буферах, затем со страницами, которые находятся только в кэше страниц операционной системы и, наконец, при чтении всего с диска). После этого я сравню результаты с двумя дисками, скрытыми под облачными абстракциями: с томом EBS из инцидента и с сервером Hetzner, бенчмарк которого я уже проводил.

Система довольно проста: моя домашняя машина с Debian. У меня работает Postgres 17 в Docker с shared_buffers = 16MB, track_io_timing = on. В качестве накопителя используется локальный SSD NVMe с ext4. Я намеренно создал таблицу такого размера, чтобы она не умещалась в кэш.

Продолжаем проводить конкурc SQL в рамках «IT-Планеты 2026». Как обычно во втором этапе участникам было предложено решить пять задач на чистом SQL. Перейдем к рассмотрению задач.

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

Чем больше растет инсталляция Zabbix, тем сложнее становится управлять ее конфигурацией. Особенно если речь идет не об одном сервере мониторинга, а о нескольких инсталляциях, десятках команд и сотнях инженеров, которым регулярно нужно что-то менять: пороги срабатывания, IP-адреса, триггеры, шаблоны или наборы метрик.

В какой-то момент мы столкнулись с тем, что прямой доступ к Zabbix оказался плохим решением: давать его всем нельзя, а проводить каждое изменение через команду мониторинга — долго. В результате мониторщики постепенно превратились в узкое горлышко в команде Сервисного центра, а история изменений конфигурации оказалась разбросана между встроенным аудитом Zabbix, заявками и переписками.

Тогда мы решили посмотреть на конфигурацию мониторинга как на отдельный объект управления и вынести ее в централизованную CMDB. Так появилась система, которая собирает конфигурацию из нескольких инсталляций Zabbix, предоставляет единый интерфейс для работы с настройками, поддерживает RFC-процессы, хранит историю изменений и позволяет откатывать их при необходимости.

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

Экран, в котором я живу 4 месяца. Не открываю IDE — всю god crm пишу внутри god crm.

Всё на скрине — строки одной postgres-таблицы. заметка, тикет, агент — одна сущность. поэтому заменило мне ноушн, обсидиан и мессенджер сразу.

Код открыт, mit: github.com/holetron/godcrm

Привет, Хабр! Я — Дмитрий Селищев,  в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER, которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.

4 июня 2026 вышла PostgreSQL 19 Beta 1. Все пишут про графовые запросы SQL/PGQ, но главная операционная новость в другом: в ядро завезли команду REPACK с неблокирующей опцией CONCURRENTLY — перепаковку раздутых таблиц без ACCESS EXCLUSIVE lock и без внешнего pg_repack. Разбираю по официальному анонсу и release notes: как это работает (спойлер — через слоты репликации, отсюда max_repack_replication_slots), чем отличается от VACUUM FULL и pg_repack, и что именно стоит прогнать на staging до GA — дисковый оверхед, documented-ограничения (команда не MVCC-safe!), бюджет слотов. Плюс честный разбор SQL/PGQ: GRAPH_TABLE убирает отдельный Neo4j для связей фиксированной глубины, но обходы переменной длины в бете пока не поддерживаются. Без ‘я проверил в проде’ — beta в прод не ставят.

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

Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные.

Недавно мы в Tarantool столкнулись именно с такой ситуацией у одного из клиентов. В этой статье расскажем подробно об этой ситуации, поделимся, как мы ее решили и почему такой подход в целом стоит использовать практически всем, кто имеет дело с PostgreSQL.

Однажды я захотел узнать что-то новое по СУБД Postgres и структурировать уже имеющиеся знания. На помощь пришла программа сертификации. Рассказываю как подготовиться к прохождению теста от Posgres Professional и на что обратить внимание в первую очередь.

Мое имя Денис Непочитой, я уже несколько лет занимаюсь базами данных в ПСБ.

Администрировал разные системы, но в основном фокусе была АБС на Oracle (автоматизированная банковская система, «сердце» банка): от решения проблем с производительностью до обновлений на новую версию. В последнее время также сфокусирован на задачах по АБС, но уже на Postgres. 

Для кого эта статья: для тех, кто только начинает свой путь в ИТ, и для всех, кто задумывается о прохождении сертификации.

Как это было — читайте ниже.

Всем привет!

Меня зовут Никита, я CEO компании VSL BI. Мы занимаемся внедрением BI-аналитики и автоматизацией отчетности для бизнеса.

Недавно к нам обратилась спортивная школа для детей.

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

Поэтому основной целью проекта стало создание единой системы аналитики, в которой данные из Alfa CRM автоматически собираются, обрабатываются и отображаются в виде дашбордов для руководства.

Новая статья из цикла про нашу OLTP-СУБД на Rust.

С самого начала мы выбрали MVCC на UNDO-логе вместо версионирования в heap, как в PostgreSQL. И годами повторяли свой же лозунг: «нет VACUUM, нет bloat». Оказалось, это правда ровно наполовину.

Heap и правда не пухнет от истории версий. Но bloat никуда не делся: он переехал в индексы, в мёртвые слоты и в сам UNDO-лог. А сборка мусора из одного механизма незаметно превратилась в пять, и мы только сводим их к единому координатору.

В статье разобрали без прикрас обе стороны. Что UNDO-модель дала: стабильный TID (UPDATE, который не трогает индексы), rollback пропорционально размеру транзакции, аналитику, не дорожающую от write-нагрузки, и AS OF как «машину времени» почти даром. И чем за это платим: главная эксплуатационная цена это долгоживущий снапшот, который молча останавливает очистку для всех.

Вопрос к тем, кто эксплуатировал MVCC-базы под нагрузкой: что меньшее зло — блокировать GC ради долгих транзакций или отдавать «snapshot too old»? Любопытно ваше мнение в комментариях.

Продолжаем рассказывать о том, как создали онлайн-платформу Playforma. Сегодня смотрим и разбираемся, что у нее внутри.

В первой части я ускорил большой интеграционный pytest-сьют с получаса до полутора минут за счёт инфраструктурных правок. Во второй проверяю следующий очевидный слой оптимизации — pytest-xdist.

Результат оказался не магическим, но полезным: -n auto дал ещё ×3.4 локально и около ×2.7 в CI. В статье показываю, почему xdist не заменяет дешёвый setup, а только домножает его; как разводить БД и Redis по воркерам; где упираются соединения Postgres; и почему память Docker VM и тюнинг Postgres не сдвинули потолок.

Про безопасные миграции написано уже тысячу раз. Мы все наизусть знаем и про expand/contract, и про обратную совместимость, и про то, что схему нельзя ломать под трафиком. А потом всё равно наступаем на эти грабли.

Вот свежий случай. Была задача на полчаса, надо было переименовать две перепутанные колонки. Прод целиком не лёг, но за одну выкатку я собрал сразу два инцидента. Причём один прилетел изнутри сервиса, а второй снаружи, оттуда, откуда я вообще не ждал.

Дальше расскажу, как так вышло

Когда у приложения появляется несколько хостов PostgreSQL, начинается головная боль: нужно динамически находить мастера после failover, выбирать реплику с нужным отставанием и гарантировать что пользователь не увидит устаревшие данные после своей же записи. DNS кешируется минутами, libpq не знает про lag, HAProxy не слышал про LSN. Разбираем как устроены существующие решения и как закрыть все три задачи через лёгкий HTTP сервис — pg-status.

Всем привет!

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

Но, мне кажется, что сейчас будет правильно сделать шаг назад и поговорить не про конкретный сервис, а про весь BaaS (Backend-as-a-Service). Как мы уже узнали из прошлой статьи, Supabase не возник сам по себе, до него был Firebase, а до Firebase были обычные самописные API, куча настроек авторизации, хранения файлов, нотификаций с вебсокетами и остального.

В этой статье мы разберем, что такое BaaS, почему он вообще понадобился, чем Firebase отличается от Supabase, для каких приложений такой подход подходит, а где уже нужен собственный backend.