За первое полугодие 2026 года мы проанализировали 7,79 млн SQL-запросов с нескольких тысяч серверов. В статье описали распределение по семействам СУБД и major-версиям.
Цена запроса не зависела от того, что ищешь: фильтр стоял над GROUP BY. Теперь отсечение идёт до агрегата, на трёх движках, без единой правки в коде приложения. До 100 раз на диапазоне по дате и в 5,3 раза на полной выборке в MS SQL Server.
Есть класс проблем производительности, который не видно на маленьких данных и невозможно не заметить на больших. Наш выглядел так: запрос искал один редкий номер заказа среди сотни тысяч объектов ровно столько же, сколько поиск, не находящий ничего. Избирательность условия не влияла на время. Совсем.
Причина оказалась в форме сгенерированного SQL. Значения props живут построчно, и запрос сначала сворачивает их в широкую строку через GROUP BY, а уже потом применяет фильтр. Условие стояло над агрегатом, то есть фильтровало результат свёртки, а не колонку. Индексу там зацепиться не за что: к моменту проверки движок уже прочитал и свернул все значения всех объектов схемы. Триграммный индекс по строкам лежал без дела.
В 3.7.1 появился шаг, который ...
Задача звучала как задача из учебника: перенести кредитный домен банка с Oracle на PostgreSQL. 70+ таблиц, чуть больше терабайта данных, 500–3000 RPS на чтение и 50–300 на запись в пике. Одно ограничение: система обслуживает клиентов и не может остановиться. Ни на ночь, ни на выходные, ни «на 15 минут на переключение».
Эта статья — не туториал «как мигрировать за 10 шагов». Таких на Хабре десятки, и половина из них сводится к «запустите ora2pg». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «об этом мы узнали за неделю до переключения».
Если вы планируете такую миграцию, читайте как чеклист. Если уже прошли — сверьте, сколько совпало.
Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин и сами проблемы — настоящие.
На одном собеседовании меня спросили про VIEW. Я ответил честно: в живых проектах они мне почти не попадались; для агрегатов надёжнее держать отдельную таблицу; а сами представления - вещь настолько нишевая, что за карьеру пригождались считанные разы. Разделение прав, долгие миграции, совместимость со старым ПО - вот и весь список. Ответ приняли прохладно. Один из собеседников сказал: “Ничего ты не понимаешь во VIEW” - и все посмеялись.
Прошло много времени. VIEW в моём коде так и не прибавилось, а вопрос остался, а вдруг с тех пор всё изменилось? Движки вышли новые. Поэтому я поднял MySQL 8.4 и PostgreSQL 17, залил одинаковые данные и прогнал основные сценарии один за другим.
Меня зовут Герасимов Михаил, я главный инженер в Россельхозбанке (РСХБ), работаю в команде автоматизации тестирования. Наш основной фокус — регрессионные автотесты на Java.
Эта публикация — первая в серии статей про CheckMateDB. Здесь мы сделаем быстрый, но технически предметный обзор продукта: что уже работает, какие задачи он закрывает и куда мы его развиваем. В следующих статьях разберем отдельные части подробнее: архитектуру модулей, ML‑контур генерации кода, практику внедрения и метрики качества.
Если коротко, то наша ежедневная реальность выглядит так: ручные тестировщики пишут сценарии в TestIT, а автоматизаторы превращают их в код. Звучит просто, но на масштабе регресса очень быстро проявляется bottleneck: между тест‑кейсом и готовым автотестом лежит большой слой однотипной инженерной рутины. Где‑то нужно аккуратно собрать тестовые данные, где‑то написать Criteria, где‑то выстроить PageHelper‑цепочку, где‑то допилить проверки и стабилизировать прогон. И да, иногда кажется, что половина автотеста уже написана… просто в 17 разных местах и в разное время.
В этой статье расскажу, как мы в команде закрываем этот разрыв с помощью CheckMateDB и почему развиваем его как единую точку входа для автоматизированного тестирования: от данных и SQL‑аналитики до AI‑генерации кода и управляемого применения изменений.
Здравствуйте, Хабровчане! Меня зовут Дмитрий, я бэкенд разработчик Java. Недавно я наткнулся на задачу, которая сначала показалась мне копеечной, а потом сожрала неделю вечеров и заставила залезть глубоко в дебри конкурентных транзакций PostgreSQL.
Всё началось с обсуждения автоматизации одной частной клиники. Поначалу казалось, что сценарий простой: пациент хочет записаться на МРТ с контрастом. Обычный календарь записи (вроде Calendly или виджетов типа YClients) предлагает выбрать мастера и время. Но на деле всё оказалось не так просто...
Пятница, вечер. Деплой ушёл, ты со спокойной душой уходишь домой. Утром открываешь дашборд: из 68 компонентов не работают 54.
Александр Крылов, 12 лет в IT и основатель конференции K8sday, рассказал, как его команда перестала тушить одни и те же пожары и написала сервис, который сам чинит типовые проблемы CI/CD ещё до того, как о них узнает дежурный. Итог: доля падающих деплоев упала в 2,5 раза, а time-to-market вырос вдвое.
Как устроен RAG поверх собственной базы знаний на PostgreSQL, какие ошибки сервис чинит сам, а какие Александр принципиально оставил на человеке, разбираем в конспекте второго занятия «Вечерней школы. ИИ для инженеров» от Слёрма.»
У Jira есть REST API, есть JQL, есть маркетплейс с дашбордами. Но как только метрики становятся чуть сложнее, чем «сколько задач закрыто за спринт», всё это упирается в потолок:
Когда говорят о DuckDB, обычно вспоминают аналитику: локальные запросы к Parquet, быстрые агрегации, ноутбуки. Но у него есть свойство, к аналитике отношения не имеющее: он умеет соединять источник и приёмник данных внутри одного SQL-плана. С расширениями для Oracle и PostgreSQL перенос данных сводится к одному запросу — без Instant Client, без OCI, без Python и без промежуточных файлов. А если одной сессии Oracle мало, чтение разбивается на параллельные шарды, читающие один согласованный снимок по единому SCN.
На Хабре не так много информации об интеграции между различными СУБД, и я решил поделиться своим опытом построения информационной системы на базе Oracle, которая взаимодействует с PostgreSQL (PG). Статья состоит их двух частей: в первой описана конфигурация СУБД, а во второй описан кейс по получению и обработке данных. Надеюсь, этот материал сэкономит Вам время при решении подобных задач.
Внешний счётчик ставится за пять минут, и обычно этого достаточно. Но у модели «сторонний скрипт с чужого домена» есть технический потолок, и на магазине я в него упёрся: запрос к третьему домену режут блокировщики и антитрекинг браузеров, на объёме включается сэмплирование, cookie тянет за собой баннер согласия (а все, кто его отклонил, выпадают из статистики целиком), и главное — поведение ваших покупателей лежит в чужой системе, рядом с которой нет ваших заказов.
Ниже — как устроен свой cookieless‑трекинг в двух проектах на Next.js: интернет‑магазин (Next.js 15.5, TypeScript, Prisma 6, PostgreSQL) и маркетплейс услуг (тот же Next.js, но pg без ORM). Код в статье — из работающих проектов, с теми решениями, которые оказались неочевидными, и с теми, которые пришлось переделать.
Сразу оговорка: это не «Метрика — зло». Для контентного сайта внешний счётчик закрывает вопрос целиком. Разговор начинается там, где аналитика — часть продукта.
Работаю в конторе, которая обслуживает госзаказчиков, и последние месяцы у меня одна большая головная боль: перевод старой оракловой схемы на Postgres Pro. Контур закрытый, интернета нет, лицензии на Enterprise нет, проприетарной ora2pgpro тоже нет. То есть из автоматики только опенсорсный ora2pg, и всё.
Штука рабочая, кто пользовался, тот знает. По разным оценкам тянет процентов восемьдесят перевода PL/SQL в PL/pgSQL. Для инструмента, который пилят несколько человек в свободное время против СУБД с тридцатилетней историей, это вообще‑то дофига )
Схема не маленькая, под сотню пакетов и триггеров, плюс куча legacy, которое живёт ещё с нулевых. И когда я первый раз прогнал её через ora2pg и увидел зелёный SHOW_REPORT, я на секунду выдохнул. Рано выдохнул, как выяснилось;)
В итоге доканали меня не эти восемьдесят процентов, а оставшиеся двадцать. И не количеством. А тем, что они не падают в момент конвертации, а спокойно ждут, пока код доедет до прода.
Три независимые попытки сделать для PostgreSQL быстрый точный десятичный тип расширением заглохли. Но не потому, что не получилось ускорить арифметику, — арифметику как раз каждое из них ускоряло. Тогда в чём же дело? Здесь я разбираю технические решения в устройстве numeric, которые приводят к высокой стоимости использования этого типа данных. Изучение провожу в сравнении с устройством типа decimal в DuckDB - будучи OLAP СУБД, он свободен от некоторых ограничений PostgreSQL, и гонясь за производительностью, выбирал другой путь развития.
Полтора года назад я написал о своём подходе к структуре FastAPI-приложений. С тех пор два крупных проекта, production и несколько архитектурных граблей заставили меня многое пересмотреть. В этой статье расскажу, что изменилось и какие решения действительно упростили мне разработку.
CTE в PostgreSQL упрощают код, но могут снижать производительность. Разбираем 4 антипаттерна, примеры EXPLAIN ANALYZE и практические способы оптимизации.
В прошлой статье мы упоминали основные SQL‑антипаттерны, способные замедлять работу базы данных. Продолжаем тему — на этот раз про CTE.
Common Table Expressions (CTE), или конструкции WITH, — привычный инструмент SQL-разработчика. Чем сложнее запрос, тем выше шанс встретить в нём WITH: код становится чище, а запутанная логика разбивается на понятные блоки. CTE используют как альтернативу вложенным запросам и временным таблицам. Однако за внешней простотой и читаемостью скрываются риски снижения производительности, которые не всегда удаётся предвидеть.
Такие запросы на первый взгляд выглядят правильными, но работают неэффективно, и проблема вылезает только в EXPLAIN ANALYZE (инструмент разбирали в прошлом гайде). Разберём четыре антипаттерна CTE, посмотрим планы выполнения и покажем, как переписать запрос. В конце — короткий чек-лист диагностики.
Эта статья может быть полезна начинающим разработчикам и аналитикам, которые уже полюбили синтаксис CTE, но хотят понять, что на самом деле происходит «под капотом» в PostgreSQL.
Мы (ну ладно, я) ждали этого больше десяти лет: в PostgreSQL 19 наконец-то завезли штатную онлайн-перепаковку таблиц. Команда REPACK в ядре и теперь больше никаких сторонних расширений и бесконечных согласований с ИБ. Да? Или нет? Эпоха pg_repack подошла к концу? Спойлер: не спешите удалять старые скрипты и утилиты. На моих тестах новая встроенная команда под нагрузкой заблокировала таблицу на три с лишним минуты, в то время как "старичок" pg_repack уложился в 0.6 секунды.
Выяснил: как устроен новый REPACK под капотом, почему он ломает привычный MVCC и в каких сценариях попытка использовать штатный инструмент на проде станет фатальной ошибкой.
Медленный запрос в PostgreSQL часто начинается с ошибки в оценках: планировщик ждёт сотню строк, получает тысячи и выбирает план, который разваливается под реальной нагрузкой.
Разберём, откуда PostgreSQL берёт статистику, как ANALYZE её собирает и по каким признакам понять, что проблема действительно в оценках планировщика.
Объектное хранилище с типами, деревьями и настоящим SQL прямо в вашей PostgreSQL/MS SQL/SQLite. FK на объекты, EF и Dapper рядом. redb против Mongo и Raven.
Чтобы хранить объекты, графы и деревья с типами, индексами и полноценными запросами, вам не нужна ещё одна база данных. Нужна та, что у вас уже есть.
redb превращает PostgreSQL, MS SQL или SQLite в типизированное объектное хранилище, не отнимая ни SQL, ни EF Core, ни Dapper. Это принципиально другой разговор, чем «MongoDB против RavenDB»: там вы выбираете отдельный движок и живёте с ним отдельно; здесь объекты ложатся в базу, которая у вас уже крутится в проде. Ниже чем это выигрывает у документных баз, с кодом, и где у redb честные границы.
Чтобы не спорить с чучелами: MongoDB зрелая серверная документная база с горизонтальным масштабированием и огромной экосистемой, и мультидокументные ACID-транзакции у неё есть с версии 4.0 (2018). RavenDB .NET-native документная база, полностью ACID, с типизированным LINQ и автоиндексами. Обе хорошие продукты. redb просто играет на другом поле и на этом поле у него сильные карты.
И учить, по сути ...
NVMe показывает сотни тысяч IOPS, а база упирается в пару сотен коммитов в секунду — знакомая ситуация, если ориентироваться на обычные тесты записи.
Разберём, где теряется производительность между write и гарантированной фиксацией данных, как на это влияют fsync, кеш контроллера и файловая система, и чем измерять реальную задержку на проде.
Большинство материалов о компрессии в PostgreSQL отвечают на вопрос «во сколько раз удалось уменьшить базу». Мы предлагаем посмотреть на проблему с другой стороны: какой ценой достигается эта экономия? В статье разбираем архитектурные компромиссы различных подходов к компрессии страниц, объясняем, почему при разработке CSM в Tantor Postgres отказались от погони за максимальным коэффициентом сжатия, и показываем результаты нагрузочных испытаний на реальных базах 1С.
