Что, если индекс не нужно создавать вообще? Знакомимся с 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 — игру на спутниковых снимках. Показывается участок съёмки сверху, без подписей, границ и координат. Надо понять, где это, и поставить точку на карте мира. Чем ближе к цели, тем больше очков, максимум пять тысяч за раунд.
Меня зовут Илья Краснопольский, я занимаюсь разработкой в области геоинформатики и градостроительства. Идея простая: сверху местность опознаётся не хуже, чем с земли, просто признаки другие.
В этой статье будет разбираться резервное копирование и восстановление PostgreSQL. Покажу все на небольшом практическом docker-compose стенде. Я специально сделаю ошибочное изменение данных, после чего восстановлю базу до состояния непосредственно перед этой ошибкой.
Восстановление данных буду делать с помощью второго PostgreSQL контейнера. Если кратко - данные WAL и base_backup будут прокидываться с помощью volume и контейнер будет стартовать с новыми данными.
Пока что рабочий стенд будет ограничиваться PostgreSQL 17 в Docker (без S3, Kubernetes, автоматизации и т.п), потом возможно сделаю дополнительные статьи, охватывающие более сложные production случаи.
В первой статье я объяснял кэш через холодильник. Продолжу тем же способом. Сейчас будет про индексы, а потом про то, почему индекс есть, а база его игнорирует.
Статья для тех, кто индексы ставил, но EXPLAIN читал по диагонали.
У банков и ритейлеров, с которыми я работала, почти всегда одна и та же боль: данные о клиенте размазаны по CRM, core-banking и платёжным системам, и никто не может ответить на простой вопрос — а что мы вообще знаем об этом клиенте прямо сейчас. Чтобы попрактиковаться в решении этой задачи и показать подход публично, я собрала pet-проект: end-to-end пайплайн, который строит единую витрину Customer 360 из синтетических данных.
Сразу оговорюсь: все данные генерируются локально скриптом и полностью синтетические. Кода или данных работодателя в проекте нет — это самостоятельная реализация архитектуры, которую я использую в повседневной работе DWH/data-аналитика.
Робот отвечал одному человеку пять раз подряд, потому что дедупликация писала в базу запрос, который никогда не выполнялся.
PGW: A PGBACKREST INTERLUDE:
(Andreas Scherbaum, Jimmy Angelakos)
Andreas Scherbaum and Jimmy Angelakos presented a quantitative analysis of the PostgreSQL CommitFest process using data collected from the CommitFest application itself.
The talk showed how PostgreSQL development has scaled significantly over the years. In 2015, CommitFest handled 418 patches from 125 authors, while in 2025 it handled 885 patches from 272 authors — roughly doubling both patch volume and contributor count. However, reviewer and committer capacity has not scaled equally well. The speakers showed that 72.1% of “Needs Review” patches currently have no reviewer assigned, and 196 out of 331 active patches in the current CommitFest have zero reviewers.
При сборе информации со сторонних ресурсов возникают одинаковые для всех проблемы — требуется проверить в своем хранилище, нет ли там уже собранных данных. Идентификаторов нет, источники разные, следовательно работать приходится с текстовыми ключами, поиск по которым гораздо медленней чем по числовым идентификаторам. Проблема обходится применением хэшей — ключевые строки хэшируются и хэш сохраняется в базе вместе с данными. При получении новой порции информации вычисляется хэш и производится индексированный поиск по нему, что намного быстрее поиска по строке.
ххhash очень удобен для этих целей, потому что возвращает 64-битовое число, а не строку, и может быть записан в bigint. Он быстрый, лаконичный, работает «на лету». Большая разрядность практически на нет сводит шансы коллизии, но если она и возникнет, достаточно добавить пробел к тексту для исправления ситуации. Правда есть одна проблема — этой функции нет в postgres «из коробки». На момент, когда мне понадобилась эта функция, я не нашел нужного расширения и написал свое, к тому же было интересно самому выполнить задачу.
Сначала я генерировал xxhash на клиентской стороне. Практически во всех популярных языках xxhash есть, но, например, в Питоне генерируется целое 64-битовое, а bigint в postgres знаковый. И если хэш попадал в верхний диапазон, то при попытке сохранения возникало исключение. Решил просто:
