Beta 2 - скоро
Должна выйти 16 июля 2026 года. Все исправления для этого релиза должны быть внесены не позднее полудня 11 июля, чтобы их успели прогнать через buildfarm.
Кстати о buildfarm: вышел PostgreSQL Buildfarm Client REL_21. В нём новые модули:
PatchStack module - новый модуль для нестандартных buildfarm-сборок для тех, кто хочет проверить стек патчей поверх ветки.
ABI check module - новый модуль запускает
abidw, чтобы обнаружить изменения ABI в установленных заголовках (использует--headers-dirи--drop-private-typesдля совместимости между версиямиabidw). Первоначальный автор - Манкират Сингх (Mankirat Singh), доработан Томом Лейном (Tom Lane).branches_targetconfig key -branches.plтеперь может использовать отдельный целевой URL для полученияbranches_of_interest.json, а не выводить его регулярными преобразованиями из основного target URL.
Стандарты
Waiting for SQL:202y: Stockholm (BMA) meeting report
Питер Айзентраут (Peter Eisentraut) - инсайдер. В июне он побывал на заседании комитета ISO/IEC JTC1 SC32 WG3, где обсуждали новые стандарты SQL и GQL. Про CQL он предоставил писать другим, более знакомым с предметом. А по SQL выделил интересные новые новшества:
QUALIFY,INSERT BY NAME,SELECT list EXCLUDE,JOIN TO ONE,обсуждались также
JOIN FOR KEY.
Postgres, ноги
Если Оптимизатор, это СЕРДЦЕ СУБД (или, всё-таки, МОЗГ? по-моему - сердце), Процедурные Языки - РУКИ, то Хранение, TAM, Table Access Methods - это НОГИ. Без надёжного хранения самая совершенная база - колосс на глиняных ногах. Сколько нужно ног для хорошей устойчивости?
PostgreSQL всегда успешно балансировал на одной мощной ноге. А с PostgreSQL 12, в 2019 появилось место, откуда могли бы отрасти новые ноги. Это место - TAM.
Прогноз был таким: уже через несколько релизов появится целая экосистема подключаемых движков хранения:
колоночные для аналитики,
с undo-log для OLTP,
in-memory для быстрой работы, ну а
старичок heap станет вариантом по умолчанию, но, конечно, не единственным выбором.
Почти так и произошло. Экосистема - есть. И цветут все цветы. Сейчас больше серьёзных, рабочих вариантов хранения, чем когда-либо за всю историю проекта. Но появились они ох не сразу, и выглядит всё немного не так, как предполагалось.
Примерно об этом написано в статье A Field Guide to Alternative Storage Engines for PostgreSQL, которая появилась на thebuild.com. Это блог Кристофа Питтуса (Christophe Pettus, гендир консалтинговой фирмы PGX - pgexperts.com). Кристоф - человек серьёзный (даже ракеты делал), и несерьёзный (сочинял электронную музыку, делал фильмы и комиксы, летал). Статья серьёзная.
В другой, более поздней статье - Table Access Methods Wake Up - Кристоф разъяснил главное: почему многообещающие TAMы (Table Access Methods) стагнировали. И с чего это сейчас многие бросились их воплощать в жизнь. Почему именно сейчас Postgres стремительно превращается в многоножку.
Идея API методов доступа к таблицам в том, что схемы хранения данных можно было бы заменять для каждой таблицы отдельно, не затрагивая остальные компоненты планировщика и исполнителя запросов. На практике всё сложней. Интерфейс TAM в нескольких ключевых точках предполагает работу с записями в формате кортежей (tuple-shaped records). Это вполне подходит для вариантов строкового хранения (row-store), но создаёт неудобства для колоночных форматов.
Кроме того, механизм оценки стоимости запросов по умолчанию не осведомлён о паттернах доступа вашего кастомного хранилища, из-за чего планировщик, не долго думая, спокойно генерит планы sequential scan для структур, которые должны использовать отсечение зон по метаданным (zone-map pruning).
Большинство ранних расширений TAM либо смирялись с неоптимальными планами (и, как следствие, низкой производительностью), либо реализовывали специфичные для расширения хуки планировщика. Второй подход создавал дополнительную нагрузку по поддержке кода и приводил к поломкам при каждом крупном релизе PostgreSQL. Ни один из этих сценариев не стимулировал волну последующих разработок в этом направлении.
Что изменилось сейчас: стоимость внедрения хуков планировщика в расширениях резко упала, а готовность сообщества и разработчиков их использовать - возросла.
Прекрасное объяснение, но и оно покрывает не все причины. Например: Undo-Log и печальная картина недостроенного долгостроя ZHeap. Но в статье A Field Guide to Alternative Storage Engines for PostgreSQL Кристоф объясняет и это (в 2 словах: сложно, дорого; в 8 словах: годы работы для интеграции с WAL, репликацией, бэкапами). EDB проект заморозили, но гитхаб жив - в 7-летней спячке. Zheap подхватил Cybertec, но и он этот чемодан тащить дальше не готов. А в комментарии к PostgreSQL zheap: Current status можно прочитать: пока что это самая важная разработка сообщества. Пока - это в 2021. На гитхабе Cybertec статус на декабрь 2020: Большинство регрессионных тестов успешно пройдены, но скорость записи пока низковата. Дальше тишина.
Кристоф не слишком оптимистичен и по поводу OrioleDB. При всём его уважении к разработке, он насторожен тем, что этот проект под крылом Supabase до сих пор предлагается в статусе экспериментального. Мы постараемся рассеять его тревогу сообщениями ниже в разделе Деньги и должности.
В A Field Guide to Alternative Storage Engines for PostgreSQL Кристоф делит подходы к TAM на 4 категории. В 1-й - OrioleDB и ZHeap, посягающие на святое Postgres - на Vacuum, во 2-й - колоночные TAM (для аналитики):
Citus columnar - append-only, сжатие 3–10×, фильтрация (прунинг) по чанкам, нет UPDATE/DELETE;
Hydra - форк Citus columnar с уклоном в векторизованное выполнение;
storage_engine - 2 TAM в одном:
colcompress(колоночный) +rowcompress(строковый со сжатием), автор - Сауло Бенвенутти (Saulo Benvenutti);pg_cryogen - лёгкий append-only TAM для архивных данных; «записал один раз, читаешь редко».
Криоген сделали в Adjust. Это немецкая компания, Андрей Казаков (Andrey Kazakov, CEO), Егор Лукомский (Egor Lukomsky, CTO), там трудятся и разработчики, известные ещё в российском Postgres-сообществе. Правда, в 2021 году компания куплена холдингом AppLovin (США) за ~$1 млрд. Про storage_engine мы писали в Postgresso #3 (88), там ноги растут тоже из Гидры.
А про AXE ни слова, увы.
Категория 3: озёрные TAM (внешнее хранение):
pg_duckdb- официальное расширение от команды DuckDB: встраивает DuckDB в бэкенд PostgreSQL;pg_mooncakeзеркало таблиц в формате Iceberg/Delta + DuckDB для ускорения запросов (мы писали ещё в Postgresso #10-11 (71-72) об этом расширении в связи с проектом Pigsty Фена Руана (Feng Ruohang) - расширение и сейчас там есть в категории OLAP);ParadeDB /
pg_search- полнотекстовый поиск в формате Tantivy внутри блоков PostgreSQL + колоночное хранение для полей фильтрации.
Категория 4, для специфического применения, а также исторически значимые и смежные проекты:
TimescaleDB Hypercore (заброшка, 2025) - прозрачное сжатие с индексами; эксперимент завершён, функционал возвращён в классический columnstore
pg_sorted_heap(0.13.0) (в начале пути, фаза Early stable), физически отсортированный heap + zone maps + векторный поиск + GraphRAG.
cstore_fdw- предок Citus columnar (на базе FDW), не используется для новых проектов;ZedStore - колонный TAM от VMware/Pivotal (2019); идеи повлияли на другие проекты, но сам проект закрыт;
pg_strom- нишевый TAM: GPU-ускорение; слишком узкая ниша для общего обзора.
На печальной истории Hypercore автор приостанавливается, т.к. она поучительна. Раз так, последуем за ним:
TimescaleDB 2.18 представил hypercore TAM, который работал со сжатым колоночным хранилищем с прозрачной декомпрессией, позволяя стандартному механизму индексации PostgreSQL работать со сжатыми чанками. Это было самое амбициозное использование TAM API крупным проектом. Команда Timescale отказалась от него в версии 2.21 и полностью убрала [sunset it - красиво сказано!] в 2.22 (сентябрь 2025), объявив, что эксперимент «не показал ожидаемых результатов». Сжатие данных осталось, но вернулось к механизму колоночного хранилища уже без TAM, доступному через разреженные индексы и существующий код управления чанками.
Этот урок стоит осмыслить. У Timescale [теперь это Tiger Data] больше инженеров и больше финансирования для работы с хранилищами, чем почти у любого другого проекта в этом списке. Они построили TAM, выпустили его, запустили в продакшене - и откатили обратно. Причины, по которым они откатили, - это именно те причины, по которым TAM API сложнее, чем кажется: кортеже-ориентированные абстракции над колоночно-ориентированными данными требуют либо строкового двойника [row shadow - опять красиво сказано], которого потом нужно синхронизировать, либо чащи [forest] специальных случаев, которые потом нужно поддерживать при обновлениях. В post-mortem от Timescale описано немного туманно [implicit], но в чейнджлогах всё понятно.
Если вы думаете, а не сделать ли колоночные TAM сейчас, в 2026 году, зарубите себе на носу: Timescale попробовал это и отказался. Это не приговор - у специфического случая Timescale было больше своих ограничений, чем у колоночного TAM общего назначения - но как точку калибровки иметь это в виду весьма полезно.
Проблемы, которые мешают плодиться ТАМам:
Планировщик PostgreSQL не «понимает» специфику нового хранилища, нужны кастомные хуки.
Интеграция с остальной системой (WAL, репликация, бэкапы) - годы работы.
Тренд 2026: вместо «своего хранилища внутри PostgreSQL» всё популярнее паттерн «PostgreSQL как каталог + внешний движок» (DuckDB, Iceberg, S3).
Экосистема, растущая сейчас, более хаотична, чем предполагалось в начале, сильнее сосредоточена вокруг всего пары архитектур (цветут не все цветы, чьи семена разбросали), поляна усыпана обломками проектов, которым не хватило финансирования или которые упёрлись в ограничения самого API.
А вот про это расширение Кристоф писал, когда ещё актуальна была версия 0.13.0. Теперь же:
Это расширение добавляет:
sorted_heap: метод доступа к таблицам, поддерживающий физический порядок строк по первичному ключу и отсечение (прунинг) блоков кучи с помощью zone-map на уровне страниц;
sorted_hnsw: интегрированный в планировщик метод доступа к индексу HNSW для встроенных векторных типов;
svec и hsvec: векторные типы float32 и float16 для PostgreSQL;
Вспомогательные функции GraphRAG в формате фактов (fact-shaped) для извлечения и повторного ранжирования графовых фактов непосредственно внутри PostgreSQL.
Версия вышла 15 мая, проект стремительно развивается: первая версия (с нечитаемым номером) выложена 1 марта. В каждой есть существенные отличия и раздел Границы стабильности: что работает стабильно, а что пока в экспериментальном статусе. Есть Stable API, полный SQL API и Stability Matrix для ясности.
Автор - Сергей Кузнецов (Sergey 'Mage' Kuznetsov) живёт в Флориде, пишет, что у него опыт работы 35+ в архитектурах безопасности, облаках и DevSecOps. Любитель экзотики: программирует в том числе на Crystal и Adams.
Он говорит, что расширение пригодится для темпоральных (временных) рядов, логов событий, IoT и вообще потоков сенсорных данных. Ну и векторный поиск, графы. В отличие от pgvector, который ограничен ~2000 измерений, его HNSW-индекс может работать с векторами до 32 000 измерений.
Конечно, есть бенчмарки. Сравнивает не только с pgvector, но и с индексами HNSW от Zvec Алибабы.
Сердце-мозг Postgres и немного о PGConf.dev 2026
Это, как было сказано в начале, Господин Оптимизатор - это то ли сердце, то ли мозг СУБД. А кто хоть что-то слышал об оптимизаторе Postgres, слышал и о стоимостной модели. Звучит немного буржуазно на вкус некоторых, зато это служило верой и правдой. До недавнего времени никто менять эту модель или даже заикаться о её несовершенстве не собирался. Ведь операции на сердце, как и на мозге, делают только когда уж совсем невмоготу. Но последнее время экспериментаторы-революционеры таки посягают на святое - на алгоритмы оптимизатора. Об этом был доклад Алёны Рыбакиной (Alena Rybakina) на конференции PGConf.dev 2026. Алёна почти что завсегдатай этой конференции - в 3-й, кажется, раз. Это любимая конференция и Кэри Хуанга (ещё бы: Cary Huang живёт в Ванкувере, работает старшим разработчиком в HighGo Software Canada) и каждый раз пишет обзоры докладов и ужинов. Он так и назвал свой обзор: PGConf.dev 2026: Why It Remains My Favorite PostgreSQL Conference. Про доклад Алёны он в нём тоже доложил. "Крамольный" доклад назывался:
Is There a Future for Genetic and Learning-Based Methods in Query Optimizers? - то есть: есть ли будущее у генетических и обучаемых методов в оптимизаторах запросов?
Алёна сравнивала несколько стратегий оптимизации, включая "родной" встроенный стоимостной планировщик PostgreSQL, штатный GEQO (Genetic Query Optimizer), SAIO (simulated annealing - имитация отжига), MCTS (Monte Carlo Tree Search). Многим из них трудно масштабироваться дальше примерно n > 12 джойнов, потому что пространство поиска растёт быстрее, чем доступный бюджет на оптимизацию.
И тут на сцену выходят архитектуры, вдохновлённые машинным обучением с подкреплением (reinforcement learning), более новые системы, использующие машинное обучение, такие как Bao (BaoForPostgreSQL профессора Райана Маркуса - Ryan Marcus, BAO=BAndit Optimizer), GenJoin (см. напр. статью Павла Сулимова, Клода Лемана и Курта Штокингера (Pavel Sulimov, Claude Lehmann & Kurt Stockinger, ZHAW Zurich University of Applied Science): GenJoin: Conditional Generative Plan-to-Plan Query Optimizer that Learns from Subplan Hints, а также SkinnerDB, - также с вполне академической статьёй-подкреплением - SkinnerDB: regret-bounded query evaluation via reinforcement learning: Proceedings of the VLDB Endowment: Vol 11, No 12.
Справедливости ради: у Алёны новые обучаемые подходы пытаются не заменить планировщик PostgreSQL, а направить, подправить его - финальное планирование остаётся за старым добрым оптимизатором Postgres. Бенчмарки показывают, что эти советчики дают выигрыш на больших и сложных аналитических запросах, а на несложных - пушка по воробьям.
Однако, Алёна не единственная, кто эту тему копнула. В Postgresso #9 (70) мы рассказывали:
Bao - логическое продолжение и развитие идей, заложенных в Neo, создатели Bao и Neo — одни и те же люди. CMAB - контекстуальный многорукий бандит (Contextual multi-armed bandit). Balsa - чисто нейросетевой оптимизатор. Minimal Simulator потому минимальный, что использует для оценки планов наивное, не зависящее от эвристик, предположение: чем меньше суммарная кардинальность плана, тем лучше. AQO появился ещё в 2017 году, развивается в рамках СУБД Postgres Pro и отдельного репозитория на GitHub. AQO 2.0 выпущен год назад.
Это из статьи Савелия Батурина (он же Safreliy): Нейронные оптимизаторы запросов в реляционных БД (Часть 2): На пути к продуктивизации (в предыдущем номере говорили о 1-й статье этой серии: Нейронные оптимизаторы запросов в реляционных БД (Часть 1).
Но вернёмся к PGConf.dev и рассказу о ней Кэри Хуанга. Там, разумеется, было немало интересного - это одно из самых важных событий сообщества.
Например: Кэри рассказывал на unconference о соц-платформе PGNEXUS.AI ("linkedin Postgres-сообщества") и СУБД IvorySQL, а его коллега Грант Чжоу (Grant Zhou) представил целый доклад The Missing Link: Connecting Tens of Thousands of Chinese Users to the PostgreSQL Core о том, как бы сократить разрыв между огромным сообществом пользователей PostgreSQL в Китае и глобальным сообществом PostgreSQL.
В Китае десятки тысяч пользователей PostgreSQL эксплуатируют крупные production-системы в финансах, госструктурах, промышленности, IoT и проектах миграции баз данных, но значительная часть этого опыта почти не попадает в глобальный процесс разработки PostgreSQL. Грант рассказал, что такие проекты, как IvorySQL и SynchDB, были созданы для решения реальных корпоративных задач, связанных с совместимостью с Oracle и синхронизацией неоднородных баз данных.
Что-то в этом слышится знакомое ...
Кстати, Грант не просто так упомянул SynchDB: там разработчик Hornet Labs, тесно связанные (мягко говоря) с HighGo. Мы можем помочь Кэри и Гранту: мы немного попутешествовали онлайн по ресурсам Поднебесной, и вот что мы писали в Postgresso #2 (87):
Есть китайский ресурс modb.pro, где, видимо, активно тусуются сообщества разработчиков баз данных. Есть там названия привычные - PostgreSQL, Oracle, MySQL, а есть там и про китайские базы данных, например: и дальше ещё о некоторых китайских базах:
Но платформа PGNexus.AI, которая вроде и есть то выпавшее звено, не простая, а ИИшная и много чего умеет: собирает блоги, новости, посты в соцсетях и обсуждения из hacker mailing list, складывает всё в единый мультиязычный поисковый центр знаний. А ещё - делает ИИ-сводки, анализ патчей, профили контрибьюторов и умеет генерить sandbox-окружения для быстрой проверки патчей и воспроизведения проблем. Да это просто шикарно! Нам бы такую.
PostgreSQL Commitfest Metrics: A Quantitative Analysis то есть метрики CommitFest PostgreSQL как количественный анализ - Андреас Шербаум (Andreas Scherbaum,
EDB) и Джимми Энджелейкос (Jimmy Angelakos, pgEdge).
Разработка PostgreSQL заметно подросла за последние годы. В 2015 году CommitFest обрабатывал 418 патчей от 125 авторов, а в 2025 году - 885 патчей от 272 авторов. Ура! Но не совсем ура: возможности рецензентов и коммитеров росли отнюдь не так же быстро. У 72,1% патчей со статусом “Needs Review” сейчас нет назначенного ревьюера, а у 196 из 331 активного патча в текущем CommitFest вообще нет ни одного ревю.
Около 73% тех, кто впервые присылал патч в 2015 году, возвращались с ещё одним патчем, но в последние годы этот показатель упал примерно до 36–37%. Время обработки патчей тоже растёт: некоторые патчи оставались открытыми более 1900 дней.
Ещё один важный момент — концентрация работы проекта среди небольшой группы коммитеров. На топ-5 коммитеров приходится 55% всех коммитов, а на топ-10 - 74%. В общем, надо срочно вербовать новых рецензентов и онбордить новых контрибьюторов.
Неожиданно идея о том, как это бутылочное горлышко расширить, пришла из другого выступления. Точнее - дискуссии на Unconference: Code, AI and You, которую вел знаменитый Джо Конвей (Joe Conway, автор PostGIS).
Сначала многие прогрессивно говорили о том, как ИИ убыстряет и упрощает разработку, потом консервативно опасались этических и прочих проблем, потом более или менее сошлись на том, что в Postgres надёжность важней быстроты. И вот тут и пришла мысль: раз уж ревьюеров катастрофически не хватает, пусть ИИ ревьюит патчи.
30 Years of PostgreSQL Retrospective - вспоминали Брюс Момджан, Ян Вик, Джолли Чен, Томас Локхарт, Вадим Михеев, Том Лейн (Bruce Momjian, Jan Wieck, Jolly Chen, Thomas Lockhart, Tom Lane, Vadim Mikheev). Направляли вспоминающих Мелани Плейгман и Джонатан Кац (Melanie Plageman, Jonathan Katz).
Сессия “30 Years of PostgreSQL Retrospective” на PGConf.dev 2026 была специальным круглым столом в честь 30-летия PostgreSQL, собравшим нескольких ранних участников и ключевых фигур, которые помогали формировать проект на его начальном этапе.
На Кэри особенное впечатление произвёл Джолли Чен, который рассказывал, как, будучи аспирантом Калифорнийского Университета в Беркли, помог добавить в Postgres поддержку SQL. Это было в 1994 году и стало фундаментальным шагом к PostgreSQL, каким мы знаем его сегодня.
PostgreSQL Conference Nepal, 2026
Постгресовых конференций много хороших и разных, на этот раз анонсируем вот эту. Она 4-я по счёту и обещает быть более представительной, чем предыдущие; 4-дневная, пройдёт 18-21 ноября в Катманду. Это, между прочим, не красивая деревушка в горах, а город-миллионник, а в стране около 30 млн жителей. Так что есть кому предлагать Postgres (правительственные структуры им тоже очень интересуются). Программа формируется, присылайте ДОКЛАДЫ!
Организаторы конференции: Nepal PostgreSQL User Group, Kathmandu University, Institute of Engineering Pulchowk Campus Университета Трибхуван и Postgres Professional. Генеральным спонсором этого года стала местная компания Dharma of Data. В оргкомитете и программном комитете представители Kathmandu University, Postgres Professional, Nepal ICT Foundation, IOE Pulchowk Campus, Outlines Research & Development, Dharma of Data, Beta Analytics и Uniaxial Softwares.
BackRest story. Happy end
В наше непростое время хэппи-энды ценятся дороже самых дорогих RAM и GPU, так что мы с удовольствием расскажем эту драматическую историю.
27 апреля: переполох
Основной мейнтейнер pgBackRest Дэвид Стил (David Steele) объявил о прекращении разработки. Объявление гласило: pgBackRest Is No Longer Being Maintained. Репозиторий был архивирован (read-only) на GitHub.
Новость Pgbackrest is no longer being maintained на Hacker News (news.ycombinator.com) собрала 100+ комментариев. Появилась зловещая аббревиатура EOL (PgbackRest is EOL) на Percona Community Forum.
Летиция Авро (Lætitia Avrot) в своём блоге вопрошает, что ж теперь будет: pgBackRest is dead. Now what?
В этой статье не только печаль (Дэвид - её друг), но и интересные детали. Например:
Дэвид — блестящий инженер. Он потратил тринадцать лет на создание одной из самых надёжных частей инфраструктуры в экосистеме PostgreSQL. Он пытался найти компанию, которая наняла бы его, чтобы он продолжал делать ровно это.
Им это было неинтересно. Им нужно было накупить побольше RAM и GPU - золотая лихорадка ИИ полностью перекорёжила приоритеты: за что компании готовы платить. Похоже, «человек, который следит за тем, чтобы ваши данные пережили катастрофу», в этот список не попал.
Речь о том, что Crunchy Data, которая спонсировала pgBackRest, и в которой работал Дэвид, была продана Снежинке - Snowflake. После этого Дэвид несколько месяцев искал работу, которая позволила бы ему продолжать работать над проектом. Он также пытался найти независимое финансирование. Не вышло.
Но сообщество всполошилось потому, что многие считали pgBackRest де-факто стандартом для бэкапов PostgreSQL, что десятки тысяч компаний, включая крупнейшие, забеспокоились о своих данных - стоит ли доверять их open source. Между прочим, backrest значит спинка дивана или кресла. Так что вполне можно сказать, что вместо уютного кресла клиенты вдруг почувствовали себя сидящими на табуретке.
Вибхор Кумар (Vibhor Kumar, ни много ни мало глобальный вице-президент по инженерии производительности в EDB (Global Vice President, Performance Engineering and Architecture - о чинах мы ещё поговорим в этом выпуске) рассуждал об open-source, как части критически важной корпоративной инфраструктуры:
Для многих пользователей PostgreSQL pgBackRest никогда не был просто очередной утилитой. Он был частью операционного фундамента PostgreSQL-среды, особенно для резервного копирования, восстановления, управления архивами, планирования recovery и готовности к аварийному восстановлению. На сайте проекта говорится, что это надёжное решение, которое масштабируется до больших баз и высоких нагрузок. И многие серьёзные организации стали всерьёз полагаться на него в своей серьёзной production-среде.
28-30 апреля: спасательная операция
Percona всполошилась из первых и конструктивно отреагировала первой: Ensuring PostgreSQL Backup Continuity: A pgBackRest Update. Объявила о готовности поддержать проект ресурсами. Ещё бы: немало её важных клиентов получили pfBackRest через неё.
Сообщество PostgreSQL мобилизовалось. Помощь посыпалась со всех сторон. Сейчас сайте проекта в разделе Спонсоры значатся:
AWS,
Supabase,
pgEdge,
Tiger Data (Timescale),
Percona,
И вот первые признаки жизни: 7 мая на GitHub появился первый за месяц Maintenance Update. До этого последний стабильный релиз 2.58.0 был выложен 19 января 2026 года.
18 мая: триумф
На сайте появилось официальное объявление: pgBackRest Will Continue! Проект был разархивирован и передан под управление сообщества.
В сообществе заговорили об уроках этого благополучно закончившегося live триллера:
Bus factor = 1. Теперь: коллективное управление.
Зависимость от спонсора. Теперь: диверсификация финансирования.
Отсутствие плана B. Теперь: создан резервный фонд.
Но, если честно, на pgBackRest свет клином не сошёлся. Это просто наиболее популярный инструмент. Альтернативы есть на все вкусы (ок, на вкусы многих, ок, некоторых). И появляются новые.
Среди альтернатив во время переполоха упоминался, например, WAL-G. Авторы Кэти Ли и Дэниэл Фарина (Katie Li & Daniel Farina), участвовал в разработке Citus (тогда ещё не майкрософтовский), где они стажировались, а сейчас поддерживается Yandex Cloud. И вот недавно появляется такая новость:
Why we rewrote WAL-G for Postgres backups in Rust: Meet WAL-RUS
Это расстарались в ClickHouse. Но WAL RUS это, видимо, не русский WAL, это просто морж, что значит китолошадь, но напоминающий/ая, что сделана она из RUST, в отличие от GOшного WAL-G. Но зачем? Короткий ответ: сборщик мусора у Go. Нужно было более предсказуемое и рациональное расходование памяти.
Это инструмент резервного копирования, который передаёт WAL через обычное репликационное соединение для непрерывного, побайтно-точного PITR. Не требует доступа к хосту, без цепочек зависимостей - единый бинарный файл. Есть адаптеры для pgBackRest и Barman, чтобы можно было подключить его или протестировать без переписывания автоматизации.
И, заодно, статья:
Does pgBackRest work with pg_tde?
Она в блоге pgstef’s blog, где stef это бельгиец Стефан Ферко - тот самый, который много сделал для pgBackRest и участвовал в его спасении.
Бизнес и его философия
Корпоративный философ: как Аристотель и Хайдеггер помогают решать бизнес-задачи - пишет Forbes Life. Но об этом пишут немало. В вашей компании ещё нет Директора по Философии (Chief Philosophy Officer)? Но есть хотя бы Директор по Этике (Chief Ethics Officer)? Даже Директора по Счастью нет (Chief Happiness Officer)? Тогда ваша/наша компания какая-то несовременная.
По мнению Виктории Михайловой бизнес-задачи помогают решать не только Аристотель с Хайдеггером. К корпоративным философами примкнули Дэниэл Деннет, Юрген Хабермас и другие. По жизни они не очень ладили и не сильно уважали друг друга. Но теперь делают общее дело (то есть бизнес) на благо компаний, направляемые директорами по философии.
Виктория - сооснователь компании Sensemakers и соавтор и академический директор программы «Тандемократия» Московской школы управления «Сколково». Компания, судя по названию, производит смыслы - тоже прогрессивное направление. Недавно, кстати, рекламировали инженеров смыслов, они придут на смену инженерам человеческих душ.
А вот автор The New York Times Бенджамин Уоллас (Benjamin Wallace) в статье Philosophers Are the Latest Hiring Target for AI Companies не предлагает нанимать Платонов и Хайдеггеров. Он говорит, что помимо некоммерческих организаций вроде Eleos, философов больше всего захантили в DeepMind и Anthropic: в каждой в штате по полдюжины философов. Но они там не философы "вообще", а философы сознания (надо ж понять, далеко ли до A.G.I. - ОИИ) или заняты вполне практическими нюансами этических правил.
PgDog. Our funding announcement
Постгрес-Пёс поднял $5.5 млн инвестиций. Совсем скромно даже в сравнении с Supabase, о чём ниже, не говоря о миллиардере-Неоне. Но и сама компания куда скромнее: PgDog - маленький стартап, говорит Лев Кокотов (Lev Kokotov), почему вы можете доверить свои данные нашему софту? И сам в этой статье отвечает, где про инвестиции совсем немного. Деньги эти трое собираются тратить на создание Enterprise edition, чтобы можно было положить Пса на AWS, чтоб была поддержка с SLA от псовой команды (или ещё псово-кошачей? до пса же был PgCat). Дайте знать, говорит Лев, если хотите попробовать нашего пса.
Такие БД, как Mongo или Dynamo существуют потому, что у Postgres есть проблема с масштабированием, - поясняет Лев, - а если б он мог запросто работать с таблицами на 100 ТБ+ и 1 млн запросов в секунду, вы б ничего другого и не искали. Вот поэтому и мы создали PgDog: тот же самый старый добрый Postgres, только с прокси перед ним. Теперь он горизонтально масштабируется.
Пол Коплстоун (Paul Copplestone, гендир и сооснователь компании, пишет в компанейском блоге о поднятой половине миллиарда. А оценка уже $10 млрд. Цель была:
Ускорить разработку open source и Postgres проектов.
Поддержать рост компании.
Улучшить благосостояние сотрудников.
Он упомянул Multigres v0.1 alpha. Multigres - это масштабируемая Postgres-СУБД, которая улучшит доступность и упростит управление. А в будущем будет горизонтальное масштабирование в стиле Vitess.
Но Пол не забыл и об OrioleDB, которая должна достичь уровня продакшн уже в этом году. Так что пусть Кристоф Питтус не волнуется (см. выше).
А руководитель проекта Multigres, Сугу Сугумаране (Sugu Sougoumarane) написал статью, полностью ей посвящённую:
Multigres v0.1 Alpha: an operating system for Postgres
Операционная система - это, видимо, всё-таки сказано для красоты. Они строят экосистему с горизонтально масштабируемой СУБД в стиле Vitess.
Анонсирована Multigres была до этого раунда инвестиций. Вот что мы писали в Postgresso 3-4 за 2025 (76-77):
Multigres под ручку с OrioleDB: Announcing Multigres: Vitess for Postgres. Supabase наняла специалиста со сложной фамилией - Сугу Сугумаране, чтобы он развивал направление Vitess for Postgres - Multigres. Сугу - сооснователь и технический директор PlanetScale, он - один из создателей Vitess, занимался ею, когда работал в Youtube. С MySQL всё прекрасно работало, можно почитать здесь: Vitess: Scaling MySQL with Sugu Sougoumarane. Теперь вот Postgres. Multigres это продвинутый прокси, должен помочь работать со всей экосистемой Postgres. Пол подчеркнул, что недавно приобретённая OrioleDB будет дополнять Multigres.
Между делом сделали ещё и A Language Server for Postgres - свою реализацию Language Server Protocol (LSP) для Postgres.
В общем, вроде разъяснили, на что собираются тратить инвестиционные деньги. Не на вечеринки.
Образование и соревнования
В этом издании учтены замечания читателей и исправлены опечатки, а также отражены такие новинки версии PostgreSQL 18, как поддержка асинхронного ввода-вывода, изменения в настройке автоочистки и появление оптимизации пропуска. Отдельное спасибо Людмиле Мантровой за редактуру изменений, накопившихся с первого издания. В печатном виде книга, как обычно, выйдет в издательстве ДМК Пресс.
«IT-Планета 2026»: задачи второго этапа по PostgreSQL - о них пишет Евгений Давыдов ака Zheka22. Он писал и о задачах прошлого года - сам их придумывает, сам о них пишет. Конкурс по SQL состоял из 3 этапов: теоретический и практический туры (онлайн) и финальный (очный) тур. Итак, задачи 2-го этапа/круга/тура:
«IT-Планета 2026»: задачи третьего этапа по PostgreSQL - придумывает и пишет Егор Рогов ака erogov из отдела образования Postgres Professional.
Вот список Егора:
о Шумахере и трассе.
Принадлежность точки многоугольнику.
Волновой алгоритм.
Кеширование спешит на помощь
Выбираем лучший ход.
Только это не 5 задачек, а этапы одного задания. Шумахеровская Трасса на картинке.
То ли соревнование YandexCon (Contest), то ли фестиваль. Формат придуман для молодёжи. Но соревновались в решении задач (приз=1млн рублей):
LLM / foundation models;
CV;
RL;
Оптимизация нейросетей.
Стартовало это нечто 21 мая, а финал был 25 июня. Победителем Баттла ВУЗов (за это ему дали, надеюсь, обещанный миллион) стал Ильдар Гайнуллин из ИТМО (не удивлён: сильный ВУЗ, где, кстати, умеют докручивать и перекручивать Postgres - это мы знаем по конференциям PGConf.Aacademy.
Разумеется там было много докладов от спецов Яндекса, там развлекали молодёжь популярные (у молодёжи?) исполнители: Slava Marlow, TOXI$, Илья Куруч, Utopia Show, Тима ищет свет, TRITIA, Сергей Мезенцев, Александр Пушной, Даниил Воробьёв, Алиса Кот. Два имени даже мне знакомы: Марлоу был битмейкером у ... у известного исполнителя, а Пушной ещё во время оно выкладывал популярные ролики в жанре нескучные уроки игры на электрогитаре.
Егор проводит сертификацию по Postgres. А вот дневник приключений соискателя сертификата:
Как ораклист сертификацию по Postgres сдавал. Но там не только мемуары, там и ответ на вопрос: зачем сдавал.
Заодно даём здесь ссылку на вполне учебную статью:
Условная агрегация в SQL: ускоряем отчеты, избавляясь от лишних JOIN-ов и подзапросов. Автор - Дмитрий Селищев ака DiSel_orenburg, да, из Оренбурга, из компании Синимекс. Там мои коллеги читали по его приглашению курс в 2024 году.
Noisia
Алексей Лесовский (Alexey Lesovsky, екатеринбургский разработчик Postgres Professional) сделал Harmful workload generator for PostgreSQL. Актуальная штука, сейчас вообще в моде Chaos Engineering. Утилита генерит гадости для стресс-тестирования инфраструктуры: взаимные блокировки, холостые транзакции и запросы, создающие временные файлы на диске.
Генератор безобидный - как ясно из названия, но расслабляться автор всё же не советует: в последнюю версию - Noisia 0.3.0 - он добавил убийцу бэкендов (через OOM) и раздувание слотов.
На этом на сегодня всё.
