PGConf.EU 2026 в Валенсии стала моей первой постгресовой конференцией. Странное чувство: никого не знаешь в лицо, но с каждым вторым у тебя есть общие нерешённые вопросы. Чёртова удалёнка! Под катом — что сказали со сцены про REPACK, JIT и параллелизм, что обсуждали в кулуарах и что в целом я вынес из этого мероприятия.
Два клика по кнопке оплаты. Два запроса к провайдеру. И внезапно один заказ превращается в две платежные сессии.
В этой статье разберём реальный кейс рефакторинга платёжной интеграции: начнём с наивного Create, попробуем локальные блокировки, столкнёмся с несколькими экземплярами сервиса и доберёмся до PostgreSQL advisory locks, идемпотентности и конкурентных Check/Cancel.
Немного C#, много PostgreSQL и чуть‑чуть «Форсажа». Посмотрим, как устроить гонку запросов так, чтобы победитель был только один.
Всем привет.
Я с коллегами пишу сервис, который использует внутренний инстанс публичного приложения Arize Phoenix (система LLM-observability — наблюдаемости за LLM-приложениями). Arize Phoenix использует в качестве БД PostgreSQL. СУБД обычно жила спокойно: AAS (Average Active Sessions — среднее число одновременно активных сессий: выполняющих запрос или ожидающих ресурса) держался около 1.0 на инстансе с 2 vCPU (виртуальными ядрами процессора). Однажды случилась аномалия: AAS взлетел до 25.
Продолжаем изучать особенности взаимодействия PostgreSQL и 1С. Эта связка нередко становится источником неочевидных проблем с производительностью. В ходе анализа инцидентов у наших заказчиков мы регулярно сталкиваемся с тонкими нюансами работы СУБД, которые существенно влияют на стабильность системы. Сегодня акцентируем внимание на «зависших» сессиях Postgres в состоянии idle in transaction – безобидном, на первый взгляд, но способном спровоцировать серьёзную деградацию работы базы.
Что мы знаем о зависших транзакциях в 1С системах?
В этой статье — про STAGING-слой нашего DWH и о том, как мы работаем с EAV-паттерном. EAV в реляционной базе — устоявшийся антипаттерн, который в большинстве задач стоит обходить стороной. Рассказываю не о том, хорош EAV в целом или плох, а о конкретном случае, когда он оказался оправдан: почему он к нам пришёл, как мы с ним живём, что он даёт и где реально мешает.
Каждые 10 минут в русскоязычном эфире Twitch и VK Видео Live в среднем 7 200 каналов. Писать их как есть - больше миллиона строк в сутки. Я храню агрегаты, и за четыре недели вышло 2 млн строк. Расскажу, как это устроено и где я три недели искал проблему не там.
Я Максим, разработчик, вечерами пишу LanolStream - инструменты для стримеров, которые мы делаем вместе со стримершей lanolkid. Стримеры часто спрашивают «во сколько лучше стримить» и «много ли у меня зрителей для моей игры». Чтобы отвечать цифрами, а не ощущениями, нужен весь рынок, а не только наши каналы.
Как поддерживать PostgreSQL и MSSQL в одном приложении, сохраняя единую кодовую базу?
На примере iLocks Online разбираем выбор провайдера в EF Core, отдельные наборы миграций, различия в последовательностях, типах данных и именовании объектов. Рассказываем, что необходимо проверять на обеих СУБД и почему подключения двух провайдеров недостаточно для полноценной совместимости.
Запрос тормозит, а EXPLAIN ANALYZE выдаёт простыню узлов, в которой непонятно, на чём остановиться. Postgres Professional выпустила бесплатную книгу «PostgreSQL 18. Оптимизация запросов» на основе курса QPT. Она объясняет, как планировщик оценивает кардинальность и стоимость, как читать планы и какие приёмы работают для OLTP и OLAP. Читать можно хоть в метро: результаты запросов уже вплетены в текст, терминал не нужен.
Облачные провайдеры удобны в использовании, но когда базы данных разрастаются до огромных размеров, становится страшно смотреть на выставленные счета. Один из способов сократить расходы — перенести базу на выделенный сервер. Кроме экономии, у выделенных серверов масса преимуществ: полный контроль над аппаратными ресурсами, отсутствие соседей по гипервизору, предсказуемая производительность. Именно поэтому компании успешно переводят свои тяжёлые проекты на выделенные серверы.
Возьмём PostgreSQL-базу объёмом 1 ТБ и сравним, во сколько обойдётся её размещение в AWS и на выделенном сервере. Заодно рассмотрим варианты переноса данных и расходы, которые стоит учесть помимо аренды.
Память агентов в тренде с того момента как они появились, чтобы бороться с галюцинациями и давать ответы и решения LLM на собственной информации. Как лучше запрашивать информацию из таблиц или из графа часто решается на вере, начитавшись постов в интернет без своих экспериментов и измерений. В исследовании Sequeda и соавторов GPT-4 отвечал на вопросы по корпоративной SQL базе верно в 16% случаев, а по графу знаний поверх этой же базы в 54%, где у графа была онтология с описанием, а у SQL схемы только DDL типы и названия таблиц/колонок.
В моем GraphRAG одна и та же информация представлена в двух разных формах. Данные из статьи “Мой PostgreSQL быстрее твоего и почти догнал ClickHouse” извлек в 34 таблицы PostgreSQL, а в граф это превратил с помощью отображения R2RML. Подключил обе формы представления знаний к агенту по MCP и задал ему 15 вопросов о статье: через SQL, через SPARQL и дал еще выбор агенту из двух этих видов сразу. В моем эксперименте агент по очереди запускался на трех LLM с открытыми весами. Их можно развернуть на своей инфраструктуре или ноутбуке и данные и вопросы не уйдут провайдеру в логи или агрегатору между вами и LLM.
Таже я проверил и рассчитал что лучше для векторного хранения и семантического поиска: lance или pgvector. Поделюсь своими измерениями на современных моделях как лучше искать и в чем хранить знания.
Обнаружил в эксперименте как DeepSeek придумал SQL-инъекцию чтобы ответить на мой вопрос.
Вы когда-нибудь читали такое сообщение от кодинг-агента? Мне не приходилось, а жаль.
Каждый раз, когда я довожу код, сгенерированный AI по моему ТЗ, я прогоняю его через ревью несколькими агентами с разными ролями и точками зрения — что-то вроде взгляда нескольких людей с разным опытом. И почти всегда получаю пачку разнокалиберных замечаний, от мелких до критических. Казалось бы, что сложного: открой новую сессию, скорми ей замечания, дай исправить, прогони ревью снова.
У этой замечательной стратегии, однако, есть одно слабое место: а мы уверены, что такой процесс сходится?
Посчитал нагрузку на сокращатель ссылок по главе 2 «System Design Interview» Алекса Сюя, записал ожидание (500 RPS, p95 ≈ 20 мс), собрал стенд в Docker и дал нагрузку через k6. Получил 24 RPS и p95 22 секунды при нуле ошибок. В статье — расчёт, стенд, EXPLAIN, почему оценка по книге не может предсказать такое, и почему кэш чинит один профиль нагрузки, а индекс — оба. Стенд открыт, можно повторить у себя.
В прошлой статье я утверждал, что Kafka не нужна, если событие и результат бизнес-операции пишутся в PostgreSQL одной транзакцией. Только ленивый не написал Главное Возражение в комментариях: слот логической репликации не делится между читателями, каждый вычитывает журнал целиком — значит, читатели и станут узким местом.
Я решил проверить это утверждение. Сравнить сколько ресурсов потребляют консьюмеры очередей по сравнению сравнению с чтением логической репликации при увеличении их количества.
Это не вердикт по выбору транспорта: в конце будут условия, при которых брокер нужен, и они следуют из тех же цифр.
Нам нужно было дёшево оценить, какая доля строк большой таблицы обладает некоторым свойством. В нашем случае свойство — «значение похоже на персональные данные», но задача общая: профилирование данных, проверки качества, любая статистика по колонке. Читать таблицу на миллиард строк целиком ради одной доли дорого, и в PostgreSQL для этого есть TABLESAMPLE SYSTEM: он читает только часть страниц.
Рецепт, который пишется сам собой, — посчитать процент страниц из оценки числа строк, взять его с запасом и ограничить результат LIMIT. Ровно так было написано и у нас. Выборка при этом тихо не видела конец таблицы, а в конце кучи обычно лежат самые свежие строки. Ниже — почему так происходит, насколько это много и как это чинится.
TL;DR. Я написал расширение для PostgreSQL 18, postgresql-leapfrog. Оно добавляет в планировщик новый узел, Index Merge Intersect: упорядоченное пересечение нескольких обычных B-tree индексов, которое останавливается на LIMIT. В результате таблице не нужен отдельный составной индекс под каждую комбинацию фильтров. На тестовой схеме с 12 фильтрами это 14 индексов вместо 33, вдвое меньше места под индексы и втрое меньше WAL на вставке. Проект экспериментальный (0.0.3), в конце статьи честно перечислено, чего он пока не умеет.
Мы — небольшая команда, делаем Зархолд: карточную MMORPG в браузере. Каждый бой в ней — пошаговая дуэль колодами, а режимов много: дуэли, арена от 1×1 до 5×5, поле боя 5×5, подземелья на троих, рейды и мировые боссы на пятерых, бои в открытом мире. Сервер — TypeScript, Fastify и node-postgres, база — PostgreSQL за pgBouncer, файлы — Cloudflare R2.
До «Хроник» у каждого режима был свой итог в своей таблице — шесть разных мест. Нам захотелось одного открытого архива всех боёв: отчёт любого боя с числами по ходам, картам и целям, топы по каждому боссу с оценкой от 0 до 100, доля побед по классам и веткам талантов в PvP. Смотреть может кто угодно, без входа (золото, почта, учётки и адреса не отдаются никогда). Так появились «Хроники сражений». Расскажу, как они устроены и какие места оказались неочевидными.
Привет, Хабр! Меня зовут Андрей, я директор департамента внутренних систем ЮMoney. Эту статью я подготовил в соавторстве с Владиславом, руководителем группы разработки и сопровождения автоматизированной банковской системы (АБС) в ЮMoney. Недавно мы завершили один из главных этапов импортозамещения ИТ-инфраструктуры: вместе с АО «ПрограмБанк» полностью перевели нашу АБС «ПрограмБанк.АБС» на ОС Linux и СУБД PostgreSQL.
В статье расскажу о технической стороне миграции: как мы строили новую инфраструктуру и переносили данные, почему автоматической конвертации кода не хватило и как мы справлялись с падением производительности. Статья может быть полезна архитекторам, разработчикам и техническим руководителям, которым предстоит перенести нагруженную систему на другой технологический стек.
Представим ситуацию: в PostgreSQL хранится большое значение — документ, бинарные данные, крупный JSON или другой объект размером в несколько мегабайт. При этом приложению далеко не всегда нужен объект целиком. Иногда требуется получить лишь небольшой фрагмент.
Например, значение занимает 10 MiB, а запросу нужны всего 100 байт.
Кажется логичным, что PostgreSQL должен прочитать только эти 100 байт. Но на практике объём работы зависит от того, как значение хранится, было ли оно сжато и какой алгоритм сжатия использовался.
В этой статье проверим поведение PostgreSQL 18.6 экспериментально. Сравним EXTERNAL, PGLZ и LZ4 и посмотрим, что происходит, если читать один и тот же 100-байтовый фрагмент из начала, середины и конца большого значения.
Цель — не найти универсально «лучший» вариант хранения. Нас интересует более практический вопрос: какую работу PostgreSQL выполняет при частичном чтении большого TOAST-значения и при каких условиях различия становятся заметны.
Все данные лежат на быстрых SSD, хотя заказы трёхлетней давности читают раз в квартал. Это значит, что вы платите за дорогую ёмкость там, где она не нужна. Разбираем, как в Postgres Pro Enterprise расширения pgpro_ilm и pgpro_usage сами переносят редко используемые секции, таблицы и индексы на дешёвые диски. Показываем правила, на что они реагируют и какие подводные камни есть у этого механизма.
«Давайте скормим модели документацию, а она сама нагенерит тест-кейсы». Вот что обычно слышишь, когда разговор заходит про нейросети в тестировании. Звучит красиво, но в моей работе это оказалось чуть ли не самым бесполезным сценарием. Я занимаюсь автоматизацией, ручные кейсы пишу не каждый день, и генерация их «по щелчку» закрывает не ту боль. Для меня настоящая боль в другом. Как понять, что вообще нужно проверять, где лежат данные, какая логика сейчас актуальна, какие сценарии уже покрыты и где документация расходится с тем, как система ведёт себя на самом деле.
Поэтому я стал относиться к LLM как к ассистенту, которому можно постепенно отдавать доступ к рабочему контексту: документации, векторному поиску по ней, базам данных, тест-кейсам и репозиторию автотестов. Всё это я подключал через MCP. И дальше расскажу, как именно всё подключал, на какие грабли наступил, а что в итоге реально выстрелило.
Это помогло. Я стал быстрее вникать в незнакомую бизнес-логику и проверять гипотезы по данным, не перечитываю каждый раз всё заново, и трачу меньше умственных сил на механический поиск. По кнопке LLM так и не генерирует ручные тест-кейсы, но это, я думаю, нормально.
