PostgreSQL *

В феврале этого года проект с красивым именем Polaris незаметно стал полноценным проектом фонда Apache. Новость прошла как-то мимо, ну стал и стал, мало ли. Между тем это одна из тех новостей, которые лет через пять, возможно, будут называть поворотной точкой. Потому что Polaris — это каталог. А каталог в мире Iceberg — то самое место, где на самом деле лежит власть над вашими данными.

Звучит громко, понимаю. Поясню, откуда такая уверенность.

Последние несколько лет хранилища данных строят по новой схеме: файлы лежат в объектном хранилище, поверх них открытый формат в виде метаданных, движки обработки живут отдельно в виде федеративного обработчика и ходят за данными. Схему назвали лейкхаусом (Data LakeHouse), а формат в ней почти везде один и тот же — Apache Iceberg. Вендоры за него отвоевались, открыли и согласовали, и все выдохнули. Данные наконец-то ничьи (формат parquet): лежат у вас, читаются чем угодно, никакой платформы-хозяина.

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

Начнём даже не с каталогов, а на шаг раньше — с того, что такое вообще Iceberg, вокруг которого последний год прыгают все вендоры.

Обе мои предыдущие статьи про этот сайт с кейсами CS2 заканчивались списком того, чего в нём нет: платежей, депозита предметов, кейс-баттлов, рефералки, KYC. Список закрыт — и почти всё сложное в нём свелось к одному вопросу: что происходит, когда несколько человек одновременно двигают одни и те же деньги. Батл на четверых в одной транзакции, порядок блокировок, из-за которого не случается дедлок, PgBouncer под Prisma и правило чтения с реплики, которое нельзя выразить типом.

Задача звучала просто: посчитать, у скольких товаров в базе есть в составе хоть одна Е-добавка. Я думал, это работа на полчаса. Работа заняла вечер, и большая часть вечера ушла на одну букву.

Пользователь нажал кнопку, сеть пропала, а браузер не знает, дошёл ли запрос до сервера. Повторите запрос — можно получить дубль. Не повторяйте — потеряете действие.

Показываю схему, которая решает обе проблемы: API без toggle, ключ идемпотентности в PostgreSQL, очередь в IndexedDB, Service Worker и проверка офлайна в Playwright. Это не полный offline-first — только защита действий в момент обрыва связи.

SQL‑инъекция через декомпиляцию: от JAR‑файла до захвата пароля

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

Корпоративная Java‑система: складской учет, веб‑интерфейс, HTTPS. Внутри — SQL‑инъекция без аутентификации в одном GET‑запросе, из‑за строки «... WHERE ID=» + параметр.

Разберем, как найти такую в приложении без исходников: декомпиляция JAR → чтение сервлетов → уязвимая строка → подтверждение через pg_sleep. Каждый шаг воспроизводим.

Если посмотреть на самые обсуждаемые публикации Go‑сообщества последних месяцев, можно заметить любопытную закономерность. Среди них почти нет материалов про новые конструкции языка, generics или очередные изменения синтаксиса.

Зато много статей про диагностику утечек горутин, профилирование памяти, внутреннее устройство рантайма, особенности современных процессоров и эксплуатацию высоконагруженных PostgreSQL‑кластеров.

В 2026 году экосистема Go значительно «повзрослела». Сама спецификация языка уже стабилизировалась, и фокус инженерного внимания сместился в сторону эксплуатации (Production Engineering) — предсказуемости памяти, автоматической диагностики рантайма, управлению ресурсами железа и устойчивости баз данных под высокой нагрузкой.

На связи команда Golang‑инженеров Авито, а ниже — несколько публикаций, которые хорошо показывают этот сдвиг.

Представь очередь. В ней все, кто когда-либо жил на Земле — от первого человека до ребёнка, родившегося минуту назад. Очередь длиной примерно в сто семнадцать миллиардов. Где-то в ней стоишь ты. Место у тебя есть с рождения, его никто не отнимет и не отдаст другому. Просто до сих пор никто его не называл.

Как посчитать порядковый номер человека по дате рождения, почему таблица из пятидесяти точек честнее плавной кривой, и как заставить Postgres держать анонимность ответов конструкцией, а не политикой — с одной дырой, которую я нашёл у себя сам.

Как открыть транзакцию на уровне use case, передать её репозиториям без зависимости бизнес-логики от ORM и правильно обработать вложенные вызовы.

Аналитик на вебинаре поинтересовался иерархическими индексами для нормативки: дерево «документ → статья → пункт», модель спускается от корня и выбирает ветку, как человек листает оглавление. И сразу про затраты: индексация — это проход по всему корпусу.

Я сравнил такой индекс с B-деревом. Потом сел считать, и сравнение выдержало.

В B-дереве на диске узел подгоняют под блок, чтобы реже перемещать головку. Здесь блок — эффективное окно маленькой модели, а движение головки — обращение к ней.

Прикинем. Шесть актов на ~200 страниц — глубина 2. 2M токенов — глубина 3. Навигатор читает 8–12 тысяч токенов вместо всего корпуса. А само дерево в законах уже есть: главы, статьи, части, пункты. Строится регекспами по нумерации, без модели. Затраты один раз и только за краткое описание внутренних узлов.

Навигатору остаётся выбрать одну из пятидесяти веток по короткому описанию. Это ближе к классификации, чем к рассуждению. В зале спросили, справится ли с этим модель на 1,5–3 млрд параметров. Интрига.

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

Разбираем переезд интернет-магазина с OpenCart 2 на Next.js и PostgreSQL. Магазин оптовый, электронные компоненты, сайту двадцать лет, в каталоге 4 751 товар. Если у вас OpenCart и вы думаете уезжать, то будет полезно почитать, что может всплыть в самый неожиданный момент.

Магазин запущен в боевом режиме, поэтому всё ниже про то, что уже перенесено и работает. Про трафик после переключения домена говорить рано, замера ещё нет. Обмен с учётной системой - отдельная большая тема, и здесь его нет.

Всем привет! Я Дмитрий Пономарев, разработчик ESB ИТ-интегратора «Белый код»! Сначала всё выглядело довольно просто: забираем данные по REST API, обрабатываем и сохраняем в PostgreSQL. Проблемы начались, когда объём таблицы вырос до десятков миллионов строк, а несколько миллионов записей пришлось регулярно проверять заново.

В одном из проектов мы столкнулись именно с такой задачей. DATAREON Platform должен был получать данные через REST API, сохранять их в PostgreSQL, хранить историю состояний и каждый день повторно проверять актуальные записи. На небольших объёмах схема работала нормально, но после роста данных стало ясно: последовательная обработка и вычисление актуальной версии записи «на лету» больше не укладываются в рабочее окно.

В этой статье разберём, как мы перестроили интеграцию: вынесли актуальность записи в отдельный признак, добавили специализированные индексы PostgreSQL, распараллелили обработку через воркеры DATAREON и предусмотрели безопасное восстановление после сбоев. В итоге производительность промышленной актуализации удалось довести примерно до 1,1–1,2 млн объектов в час.

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

12 сентября вышла redb 4.0.0. Четыре продукта экосистемы (хранилище, интеграционный движок, рантайм и сервер идентификации) получили общий мажорный номер: 76 пакетов, внутренний аудит безопасности и сборку на .NET 10, который Microsoft поддерживает до ноября 2028 года. Для инженеров изменения разобраны в отдельной статье. Этот текст для тех, кто решает, на чём строить бэкенд: что экосистема заменяет, во что обходится, какие риски снимает и что важно знать до старта.

Коротко, из чего она состоит:

SELECT FASTTRUNCATE нет в документации PostgreSQL, но на боевой базе эта команда занимала 12.9% времени всех запросов. Разбираем, как платформа 1С на самом деле работает с временными таблицами, почему УНИЧТОЖИТЬ в запросе ничего не уничтожает и что изменилось в 8.3.25.

Не открою секрет, если скажу, что обычный поиск по ключевым словам уже не особо помогает. Чтобы нейросети могли отвечать точно, опираясь на ваши корпоративные базы знаний, им нужно «понимать» смысл текста. А это уже сложнее, чем просто искать точные совпадения букв. 

В этой статье мы разберем, как устроены векторные базы данных, почему без них не работает современный RAG, чем они отличаются от привычных реляционных БД и как выбрать подходящий инструмент для своего проекта.

Привет, Хабр. Я хочу рассказать историю, которую вы уже, наверняка, где-то слышали. Только с другой стороны.

Пару месяцев назад я сидела на созвоне с техдиром стартапа, который делал RAG-систему для юридических документов. Он сказал, что они уходят с Postgres на Pinecone, потому что Postgres для векторов не тянет, это же очевидно. Я спросила, сколько у них векторов. Оказалось, тысяч двести, может, триста. Я уточнила, пробовали ли они вообще pgvector. Выяснилось, что нет, решение приняли по общему ощущению, что Postgres для этого не годится. Ощущение было не на пустом месте, два года назад так и было. Я не стала спорить. Просто открыла документацию pgvector и скинула ссылку. Через неделю он написал, что оно работает. Даже быстрее, чем они думали. Ещё через месяц они запустили прод. На одном Postgres. Без Pinecone. Без отдельной векторной базы. Без трёх месяцев инфраструктурной работы, которую они уже успели запланировать.

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

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

Горел. Ещё как.

Это продолжение того же разбора, но на слой выше — про HikariCP, дефолтный пул соединений в Spring Boot. Тот самый, который «просто работает», пока не перестаёт. Проекты те же, что и в статье про миграцию и в статье про PostgreSQL: банковская система после переезда с Oracle (терабайт, 70+ таблиц, 500–3000 RPS на чтение и 50–300 на запись в пике) и enterprise-платформа на Java/Spring, где PostgreSQL жил под Hibernate. Разные команды, разные нагрузки, но сюжет один: сервис встаёт, в логах Connection is not available, и первое, что делает любой человек, — лезет крутить maximumPoolSize. И почти всегда делает хуже.

Это не туториал «как настроить HikariCP за 10 строк». Таких на Хабре хватает, и половина из них сводится к «поставьте пул побольше». Здесь — список мест, где у нас всё ломалось, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой».

Если вы сейчас живёте на HikariCP — читайте как чеклист. Если уже прошли через это — сверьте, сколько совпало.

Дисклеймер: проекты под NDA, названия, точные объёмы и часть деталей изменены. Порядок величин, конфиги и сами инциденты — настоящие.

Меня зовут Кирилл Манин, я почти шесть лет работаю в команде SQL DBA и занимаюсь развитием платформы баз данных Авито.

Почти всё это время к нам регулярно обращались разработчики микросервисов: «Можно нам читать с реплик?» и «Как подключиться к реплике для чтения?». Мы всегда отвечали одинаково: платформа не поддерживает чтение с реплик, и добавлять такую возможность мы пока не планируем.

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

SQL-запрос выполнился без ошибок, дашборд обновился, цифры выглядят правдоподобно — и всё же выручка внезапно выросла на треть. Причина может скрываться в одном JOIN, незаметном NULL или неверной границе периода. Разбираем семь ошибок в SQL-агрегациях, которые не ломают запросы, зато вполне способны сломать выводы из данных.

Мониторинг редко начинается с разработки собственного кода. Обычно всё гораздо прозаичнее: устанавливаешь готовый агент, подключаешь его к существующей системе мониторинга, убеждаешься, что метрики поступают, и переходишь к следующей задаче.

У нас получилось немного иначе.

При подключении нового пилотного контура PostgreSQL к Zabbix выяснилось, что Mamonsu успешно работает с базой данных и собирает метрики, но не может передать их на сервер мониторинга, если тот принимает от узла только защищённые соединения с TLS PSK.

Можно было изменить настройки Zabbix или построить обходную схему вокруг штатного zabbix_sender. Вместо этого мы решили доработать сам Mamonsu. В результате появилась поддержка TLS PSK и сертификатов с сохранением совместимости как со старыми серверными версиями Python, так и с современными версиями Python, где PSK уже поддерживается стандартным модулем ssl.

Доработку проверили на пилотном контуре, после чего отправили разработчикам Mamonsu в upstream.

В 2023 году мы писали о временных таблицах в PostgreSQL и о том, как перенести их на RAM-диск. Это помогло: в наших измерениях доля ext4 в профиле процессора упала с 13,5% до 1,6%, и про диск мы с тех пор не вспоминали. Однако создание, очистка и удаление временных таблиц остались обычным DDL — с изменениями системного каталога и сильными блокировками, которые держатся до конца транзакции. Оказалось, что это отдельная цена, и платить её приходится в самых неожиданных местах.

На одном сервере активные бэкенды периодически застревали в ожиданиях LWLock:LockManager. На другом отставала логическая репликация и накапливался WAL. Выглядело это совершенно по-разному, а разбираться в обоих случаях пришлось в одном и том же: в том, что происходит в PostgreSQL, когда временные таблицы создаются и очищаются тысячами. Начнём с блокировок — там обнаружился массив из 1024 счётчиков, который занимает четыре килобайта, не настраивается и не менялся с 2011 года, и выяснилось, что временные таблицы одной сессии могут лишать обычные запросы всех остальных сессий быстрого пути получения блокировок.