PostgreSQL *

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

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

При подключении нового пилотного контура 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 года, и выяснилось, что временные таблицы одной сессии могут лишать обычные запросы всех остальных сессий быстрого пути получения блокировок.

Всем привет!
Я порядка 15 лет занимаюсь администрированием СУБД, а в данный момент работаю на должности старшего инженера по базам данных.

За свою карьеру мне довелось попробовать в работе разные системы мониторинга СУБД, но больше всего мне нравился Spotlight for SQL Enterprise. Это, наверное, лучшая система мониторинга, с которой мне доводилось работать.

К сожалению, Quest Software ушел из РФ, и компании, которые вынуждены соблюдать санкционные режимы, больше не могут им пользоваться. В попытках найти близкие альтернативы я понял, что ничего похожего на рынке нет, и понял: вот она, ниша, в которой можно проявить себя и применить весь свой опыт! :=)

Так появился Lumen.

Сначала — об архитектуре.
Lumen имеет аналогичную архитектуру со Spotlight, есть Diagnostic Server который устанавливается на Windows host. В нем настраиваются подключения к целевому серверу. На целевой сервер ничего устанавливать не нужно, необходимо лишь наличие прав на стороне сервера.

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

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

9 января 2026 появилась первая строка кода. Сегодня это Оракул — оркестратор ИИ-агентов: 465 коммитов, ~20 000 строк Python, четыре LLM-провайдера, планировщик, MCP-сервер и первые клиенты. Загрузка по основной работе никуда не делась, так что весь проект — это примерно 4 часа в день.

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

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

Именно здесь появляется Tantor Polar — распределенная СУБД с разделением вычислений и хранения и 100% совместимостью с PostgreSQL. На ее основе построена машина баз данных Tantor XData Gen3, объединяющая мощные вычислительные узлы, высокопроизводительное общее хранилище и высокоскоростную сеть c RDMA в единую систему. В этой статье мы покажем, что эта архитектура дает на практике — рассмотрим устройство синергично работающих программных и аппаратных модулей позволяющих достичь высоких показателей в популярных нагрузочных фреймворках, таких как TPC‑B (250 тыс. TPS) и TPC‑C (2,6 млн NOPM). 

В прошлой статье я рассказывал, как мы перевозили терабайт банковской базы с Oracle на PostgreSQL без даунтайма. Там был раздел про производительность, и в комментариях несколько человек спросили примерно одно и то же: «а что конкретно вы дебажили и как?».

Это продолжение. Три инцидента из двух разных проектов — банковской системы после миграции и enterprise-платформы на Java/Spring, где PostgreSQL жил под Hibernate. Разные домены, разные команды, но сюжет один: запрос, который вчера работал, сегодня не работает, а EXPLAIN показывает, что всё хорошо.

Если вы пришли в PostgreSQL из Oracle или из мира, где база — это «то, куда ORM пишет», три четверти статьи будут про вещи, о существовании которых вы не подозревали. Я тоже не подозревал.

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

Что, если индекс не нужно создавать вообще? Знакомимся с iHeap — альтернативным методом доступа к таблицам PostgreSQL, где BRIN-индексирование встроено «из коробки» и работает автоматически для всех подходящих столбцов.

Раскатка обновлений INTEKEY WMS больше не зависит от того, у кого сегодня открыт SSH и кто помнит, какая сборка где стоит. Мы создали оркестратор, который берёт на себя весь цикл: сборку, проверки, раскатку по стендам, точки отката и отчётность. Ниже как он устроен.

Как я собрал бесплатный сервис метаданных книг на Java и Spring Boot — с EAV/Pivot-схемой БД вместо ALTER TABLE на каждое новое поле, агрегацией нескольких открытых источников. Плюс обновлённый плагин для Obsidian.

pg_anon — полностью открытый инструмент для PostgreSQL, который ищет персональные данные по заданным правилам и выгружает копию базы уже замаскированной. За год проект заметно вырос: частичный дамп и восстановление, поддержка сложных схем, REST API, новый CLI. В статье разбираем все режимы на реалистичной демо-базе.

Что делать, если WAL удалён, сервер убит kill -9, база после pg_resetwal не хочет открываться, а бизнес стоит уже сутки? Это не гипотетический вопрос, а реальный кейс с кластером PostgreSQL для 1С на 2,5 терабайта данных. Расскажем историю о том, как без бэкапов, без WAL-архивов и почти без надежды вытащили критичные данные 1С-инфобазы. А в конце — неожиданный поход в апстрим PostgreSQL с патчем для pg_dump.

Продолжаем исследовать настройки памяти в Postgres и сегодня поговорим о связке настроек в ОС и СУБД. Речь пойдет о связке hugepages (Linux) и shared_buffers (Postgres).

Триггером для исследования послужила реальная жизненная ситуация у нашего клиента на поддержке производительности его ИТ-системы. Однажды утром…поступило обращение, что Postgres перестал запускаться вроде бы без видимых на то предпосылок: «мамой клянусь, ничего не делали с базой».

Первый файл, который я получил при переезде своего магазина с InSales, парсер прочитал как одну длинную строку мусора. Выгрузка заказов оказалась в UTF-16 LE с BOM и табуляцией вместо запятой — ни один разумный дефолт не подошёл.

Тогда это выглядело как разовая неприятность: поправил чтение, написал скрипт, ночь работы, всё уехало, скрипт лёг в репозиторий. На следующем проекте он не переиспользовался — другая платформа, другие колонки, другие правила. На третьем стало видно, что повторяется почти вся работа: связать заказ с клиентом, не создать дублей, не потерять адреса страниц, уметь перезапуститься. Разное только на входе — кодировка, формат, названия колонок, единицы измерения.

Отсюда вывод, к которому стоит прийти раньше, чем на третьем проекте: середина должна быть одна, а платформенная специфика — жить в тонком слое на входе. Ниже — как этот каркас устроен у меня, с кодом из работающего проекта: собственного магазина, который я перевёз с InSales на свой движок на Next.js и PostgreSQL.

Сразу оговорюсь про доставленные миграции: полностью пройдена одна — та, о которой пойдёт речь. Про требования к адаптерам под 1С‑выгрузки и товароучётные API дальше я говорю как о проектных требованиях к каркасу; готовыми кейсами они не являются. Это важно, чтобы вы правильно оценили вес каждого утверждения.

Резонный вопрос до всего остального: почему не готовый инструмент. Airbyte, n8n, коннекторы к товароучётным системам делают ровно это — вытащить, преобразовать, положить. Для регулярной синхронизации они и есть правильный выбор. Разовая миграция магазина отличается тем, что сложность сидит не в перекладывании строк, а в доменных правилах: как собрать заказ из нескольких строк, что делать с позицией, товара которой больше нет в каталоге, как при повторном прогоне не затереть свежие данные старыми. Эти правила всё равно пишутся руками, а в визуальной цепочке трансформаций их неудобно тестировать и нельзя перезапустить кусочком. Поэтому середина своя, а тонкими остаются края.

Всё, что ниже — из живого пет-проекта: бот начисляет участникам голосовых каналов баллы лояльности (LP), а на эти баллы люди устраивают пари в стиле Twitch Predictions.

DuckDB — популярная база данных, которая примечательна тем, что имеет расширение для PostgreSQL, позволяющее выгружать данные из PostgreSQL в DuckDB. Синтаксис SQL, используемый DuckDB, близок к синтаксису PostgreSQL, что делает DuckDB популярной аналитической базой в дополнение к PostgreSQL. Компания MotherDuck писала о DuckDB как о прекрасном дополнении PostgreSQL. Однако, в конце августа появилась новость о том, что Amazon приобретает создателя DuckDB, компанию Duck Labs. Генеральный директор компании MotherDuck написал статью в корпоративном блоге MotherDuck об этом. Статья интересна для понимания того, как он оценивает перспективы развития DuckDB. При приобретении Greeenplum компанией Broadcom предвестники были, приобретение Duck Labs стало неожиданностью.

Анонс четвёртой версии redb.Core: ссылки грузятся по обращению, уникальность на любом поле, схема обновляется сама. Бесплатно, три СУБД, Free и Pro одинаково.

Готовится redb.Core 4.0. За год это первый мажор такого масштаба: не смена номера, а качественное расширение функционала. Он про три вещи, которые чаще всего просили: ленивая загрузка ссылок между объектами, уникальные ключи на любом поле и обновление схемы базы без ручных действий администратора. Всё вместе, на трёх СУБД сразу и без разделения на «в Free так, в Pro иначе».

Коротко, что изменится для приложения.

Про BiHA (встроенную отказоустойчивость Postgres Pro) написано немало, и почти всё написано вендором. Материалы честные и полезные, но все статьи написаны в одном продуктово-обзорном жанре: как устроено, из чего состоит, что умеет. Практической и эксплуатационной боли в них нет. Я решил зайти с другой, инженерной стороны, с замерами, аварийными сценариями и цифрами.

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

История об асинхронном серверном EAV‑движке, epoll'е, битовых полях и шардинге, который не смог.

Это должен был быть очередной вялотекущий рутинный проект TCP сервера, listen socket, пул потоков, пул соединений, СУБД и синхронизация всего этого добра. Сказать, что скучно — ничего не сказать.

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

Этот сервер не стоит миллион рублей. Это обычная облачная виртуалка: 4 vCPU, 4.5 ГБ RAM, AlmaLinux 8. И она выдала 1М+ RPS на пакетах по 4 байта. Сервер стоял на 40% CPU.

Я прогнал тесты ещё несколько раз — результат не менялся. Сравнил счетчик сервера со счетчиками эмуляторов. Сервер стабильно держал 1М с копейками. Запросил информацию по производительности NGINX. Да ладно!?

ora2pg переносит схему с Oracle на PostgreSQL, и в целом переносит хорошо. Интересное начинается там, где он чего-то не осилил: он не падает и не ругается, а молча делает не то.

Процедура с AUTHID исчезает из вывода целиком, без ошибки и без строки в логе. TO_DATE с форматом RR молча возвращает 1 год до нашей эры. LONG RAW превращается в text, хотя сам ora2pg документирует bytea. Обработчик исключений после конвертации ловит SQLSTATE, которого PostgreSQL не возбуждает никогда.

Двадцать таких мест, все проверены на реальном ora2pg 25.0 и живом PostgreSQL 16, по каждому написано чем чинить.

Геогессеры обычно строятся на панорамах улиц: вид с земли, а вы ищете вывески, дорожные знаки, номера машин. Работает, но угадываете вы в итоге по надписям.

Я сделал Location King — игру на спутниковых снимках. Показывается участок съёмки сверху, без подписей, границ и координат. Надо понять, где это, и поставить точку на карте мира. Чем ближе к цели, тем больше очков, максимум пять тысяч за раунд.

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