Бета 2 вышла, в ней 14 исправлений, если считать за 1 исправление целый набор поправок к SQL/PGQ property graph. Понемногу выходят статьи о достижениях 19-й версии.

pgrust это СУБД или злая шутка?

Майкл Малис (Michael Malis), житель Сан Франциско, основатель freshpaint‑io, работал в компании Heap — человек в мире Postgres не слишком известный, хотя давний пользователь. Он, скорее, из мира фанатов Rust и Common LISP. Он был бы возмутителем спокойствия Postgres‑сообщества — да чего там: ИТ‑сообщества — если б там сейчас было какое‑то спокойствие.

У него есть свой сайт — malisper.me. Там многое рассказано, хотя наиболее шустро новость разошлась с форумов — с рэддит: pgrust: Postgres rewritten from scratch in Rust, currently passing 34% of the Postgres test suite, или с ycombinator: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests. В рунете новость появилась на OpenNET.ru: pgrust — клон PostgreSQL на Rust, проходящий все регрессионные тесты.

На сайте Майкл публикует новости своего проекта pgrust. Обратите внимание на тайминг:

Сразу приведём здесь ресурсы самого Майкла:

Переписывал он на Rust не один. Во‑первых, вместе с Opus, щедро заплатив ему $100k. Ещё и транслятор c2rust использовали. Но Майкл и сам не ленив: он участвует в AoC (Advent of Code), мы об этом писали в номере Postgresso № 6 (55).

Кроме того он делал проект ещё и вместе с вполне кожаным другом — Джейсоном Зайбелем (Jason Seibel).

Им мало просто переписать весь Postgres для спортивного интереса. Они искренне хотят его улучшить.

В статье о Всадниках Апокалипсиса Майкл ругается на:

  1. Вакуум и Wraparound — это понятно, все ругаются. Майкл думает начать с 64-битных Xid и задумывается о других TAM (Table Access Methods — о том, что с ними творится последнее время, мы писали в Postgresso #5).

  2. Маловато соединений держит, и слабый параллелизм в исполнении запросов. Майкл вместе с Rust переходит на треды вместо процессов.

  3. Плохие планы запросов — обычно Postgres выбирает правильные алгоритмы, но если ошибается, то ошибается ооочень сильно — считает Майкл. Он собирается научить pgrest разумно действовать в таких случаях.

  4. Это, на мой вкус, самый неожиданный пункт: JSON. Что с ними‑то не так? По ним нет нормальной статистики, считает Майкл. И даже приводит статью своего бывшего коллеги по Heap: When To Avoid JSONb In A Postgresql Schema

Postgres только что (8 июля) отпраздновал 30-летие (см. ниже в нашем обзоре). За это время в него вложили столько человеко‑часов, что против pgrust это Вечность против мгновения. Можно понять ярость и даже бешенство некоторых комментаторов в форумах, их ругань.

Никто в здравом уме не запустит такую штуку в прод. Но автор и не претендует (пока) на это.

Можно спросить себя и других: и чего стоят эти многочисленные регрессионные тесты, если ИИ‑поделка их проходит играючи? Достаточно ли глубоко копают тестировщики?

Можно присвистнуть, покачать головой и задумчиво произнести: «это только начало». И оказывается, что в форумах уже кое‑что нашли:  We're building Postgres in Rust. Using the LLVM of databases. Мы — это компания Turso (до этого они переписали на Rust SQLite). Но может через пару лет таких проектов будет 100, а форки будут ветвиться тысячами? И это будет хаос? Или это будет экспериментальная площадка нового поколения, и всё это на пользу Постгресу и Прогрессу?

Итак: процессы vs. треды

В сообществе на тредах отнюдь не поставили крест. Тредов пока нет, но их не только обсуждают, но и делают понемногу. Хотя в их необходимости сомневаются авторитетные люди. Сначала немного ликбеза:

Processes and Threads

Бен Дикен (Ben Dicken) из PlanetScale объясняет в корпоративном блоге разницу между процессами и потоками (тредами) очень наглядно и с низкого уровня: с нулей и единичек. Он приводит Postgres как удачный пример СУБД на процессах, а MySQL — как удачный пример СУБД на потоках. В PlanetScale исторически занимались MySQL и Vitess, но последнее время торжественно заявляли о претензиях на место под солнцем Postgres. Летом они заявили о готовности: PlanetScale for Postgres is now GA.

Нам легче всего отследить некоторые ходы полемики по собственным публикациям — они не всё охватывают, но картину дают.

Ещё в ноябрьском номере за 2020 — Postgresso 26 — тема затрагивается, хотя и косвенно в контексте описания интересов нового члена Core Team Андреса Фройнда (производительность, масштабируемость и хранение). Там дается интригующая отсылка: «треды, а не процессы? Спойлер Андреса: если аккуратно померить, то...» (с отсылкой к его исследованиям накладных расходов процессной модели): Measuring the Memory Overhead of a Postgres Connection. Речь о серии из 3 статей о производительности PostgreSQL при большом числе соединений.

Статья об издержках памяти начинается с популярного мотива — а если бы треды, а не процессы? Спойлер Андреса: если аккуратно померить, то издержки меньше 2 мебибайтов. А неаккуратно — это при помощи top и ps.

Для более тонких замеров памяти Андрес использует системные /proc/$pid/status и /proc/$pid/smaps_rollup. Так можно увидеть значения VmRSS, VmRSS, RssAnon, RssFile, RssShmem — если вы не знали, что это, то из статьи узнаете и поймёте, почему они важны. Чтобы не обмануться с причиной перерасхода памяти, он замеряет с включенным и отключенным huge_pages. Ещё: надо помнить о copy‑on‑write при форке процесса.

В июльском номере за 2023 — Postgresso № 6 (55) — была целая секция на эту тему. Обильно процитируем — для удобства:

Новый виток старой дискуссии. Джонатан Корбет (Jonathan Corbet) решил обобщить дискуссию в рассылке.

В июне Хейкки Линнакангас (Heikki Linnakangas, теперь мы его знаем как сооснователя Neon) предложил начинать переделку всей модели Postgres с процессов на потоки (треды):

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

Там же он предложил краткий перечень задач. Понятно, что за один релиз не перейти на треды. Андрес Фройнд (Andres Freund) поддержал:

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

«За» высказался и Роберт Хаас (Robert Haas, EDB):

PostgreSQL плохо масштабируется на больших системах, в основном из‑за потребления ресурсов этими процессами. Такая проблема не у всех СУБД, и Postgres не изменить в этом отношении без кардинальных архитектурных изменений. Для этого даже перехода с процессов на треды будет недостаточно. Но это подтолкнуло бы к другим изменениям.

Не смотря на поддержку таких авторитетных людей, заявление Хейкки не подтвердилось. Достаточно ответа Тома Лейна (Tom Lane, Crunchy Data), остающегося самым продуктивным разработчиком Postgres, чтобы констатировать: мощного консенсуса нет:

Я думаю, что это будет катастрофа. Огромное количество кода будет в результате поломано.

С самого начала этой дискуссии вспоминали, что в 2017-м Константин Книжник (тогда в Postgres Professional, потом в Neon) экспериментировал с потоками. Сам он сказал, что это оказалось проще, чем он думал. Но с тех пор он не продолжал этим заниматься.

Автор заканчивает статью так: цельтесь в звёзды, попадёте на Луну. Если цели нет, то и останетесь в Нигде.

Для LWN.net Джонатан написал ещё одну (как минимум) статью в том же жанре: PostgreSQL's fsync() surprise. Тоже с большими и многими ветками комментариев. Она написана ещё в 2017-м.

И на конференциях, на самых ключевых, нередко эту тему обсуждали:

Postgresso 3–4 за 2025 (76–77) В обзоре конференции pgconf.dev 2025 отмечалось, что тема многопоточности остается актуальной на самом высоком уровне. Упоминались два профильных доклада:

  • «Investigating Multithreaded PostgreSQL» — Томас Мунро (Thomas Munro).

  • «Multithreaded PostgreSQL (2025 edition)» — Питер Айзентраут (Peter Eisentraut).

И так далее.

PG‑wiki есть страничка Multithreading. Там есть в том числе список ресурсов на тему:

Итак: вакуум. И MultiXact

Сейчас об отмене вакуума говорят уже ссылаясь на произведение Александра Короткова (Alexander Korotkov) OrioleDB — самое doable, как говорят англоязычные (о новых методах доступа почитайте в прошлом номере — Postgresso #5 (90) — и статье Table Access Methods Wake Up Кристофа Питтуса (Christophe Pettus). И напоминаем, что по словам Пола Коплстоуна (Paul Copplestone, гендир и сооснователь компании) OrioleDB должна достичь уровня продакшн уже в этом году.

Potential Consequences of Using Postgres as a Job Queue

Эту статью Ричард Йен (Richard Yen) опубликовал в собственном блоге, но оригинал, он говорит, на Microsoft Community Hub. Излагает он чётко. Проблемы:

  • MultiXact SLRU,

  • раздувание (распухание, разрастание — короче: bloat),

  • CPU и издержки блокировок (lock overhead).

Как бороться:

  • постгресовые средства: Advisory Locks,

  • pgq (Skytools),

  • PgQue — Николай Самохвалов (Nikolay Samokhvalov) допилил pgq,

  • Redis,

  • Kafka.

Тема MultiXact не даёт ему покоя: есть ещё его статья:

XID Wraparound's Equally‑Evil Twin — то есть зловредный близнец: MultiXact ID wraparound. Дальше, правда, Ричард противоречит сам себе, называя близнеца двоюродным братом (there’s a quieter, less‑discussed cousin). Но более странно другое: он ни словом не упоминает важное новшество Postgres 19: 64-разрядные структуры MultiXactOffset и MultiXactMembers (автор Максим Орлов — Maxim Orlov, ревьюер — Хейкки Линнекангас — Heikki Linnakangas).

Ричард легко и просто пишет на интересные темы. Вот, например:

The Postgres Performance Triangle

Постановка вопроса немного напоминает CAP‑теорему: помни о всех 3 вершинах треугольника:

  • Память (Memory Allocation).

  • Производительность диска (Disk I/O).

  • Конкурентность (Concurrency).

И отдадим должное: по теме PgQue, например, Ричард рекомендует статью Кристофа Питтуса (Christophe Pettus, PGX) в блоге The Build - как более технологичную:

PgQue: Two Snapshots and a Diff.

Из неё мы узнаём, что проект представляет собой порт PgQ — движка очередей эпохи Skype образца 2007 года, переписанный на чистый SQL и PL/pgSQL. Базовый алгоритм остался в точности таким же, как в оригинальной версии Марко Крина (Marko Kreen).

Что особенно интересно — пишет Кристоф: этот алгоритм незнаком целому поколению разработчиков PostgreSQL, которые привыкли организовывать очереди исключительно с помощью SKIP LOCKED. И он оказывается куда более элегантным, чем они могли бы предположить.

Кристоф Питтус пишет и о MultiXact*:

MultiXact Members at 64 Bits: One Less Wraparound to Worry About

И в статье есть важный раздел: что сломалось.

В целом The Build стал с некоторых пор выглядеть странно: статьи на разные темы — обычно интересные и технологичные — потонули в полноводном потоке, в бесконечном сериале All your GUCs in a row.

Приведу здесь слова Павла Лузанова (руководителя нашего отдела образования, напоминаем об его обзорах коммитфестов):

В постгресе 402 конфинурационных параметра (в 19-й версии). Кристоф взялся за большой труд: описать каждый параметр. И идет по алфавитному порядку. gin_fuzzy_search_limit - 131-й, так что впереди еще много. Это не первая попытка сделать описание конфигурационных параметров.

Есть еще вот такой сайт: https://postgresqlco.nf/ Но этот сайт скорее удобен тем, что можно найти быстро, что в какой версии появилось, описание из документации и ссылки на SO. А Кристоф прямо вкладывается в предназначение каждого параметра, зачем он нужен и почему.

Всё‑таки задержусь ещё на Бильде: The Maintainer Is Not the Owner — вот интересная тема, становящаяся — опять же — более актуальной.

Ну а пока автовакуум не отменили, вот статья Лауренца Альбе (Laurenz Albe). Как всегда серьёзная, с листингами:

Monitor autovacuum: the queries I prefer — в статье и о рэпараунде, и о раздуваниях‑распуханиях, и о заморозке, и о записях‑мертвяках. То есть — о главном.

В ИИ‑контексте

Сейчас, вообще‑то, вся ИТ‑отрасль в контексте ИИ. Отсюда нервозность, которую подкрепляют главные фигуры. Главней фигуру, чем Папа Римский Лев XIV (он же Роберт Фрэнсис Прево), трудно придумать, а он придумал (со своими консультантами, конечно) ИИ‑Энциклику Magnifica humanitas (Великолепное человечество). Сотни страниц, сотни пунктов. Вышла 15 мая 2026 года по случаю 135-летия социальной энциклики Rerum novarum) выпустил свое первое программное послание, полностью посвященное искусственному интеллекту Pope Leo’s “Magnifica humanitas”: AI must serve humanity not concentrate power — Vatican News

В Ватикане по этому поводу выступил атеист Кристофер Олах (Christopher Olah), сооснователь Anthropic. Об этом рассказывает Гардиан в The Guardian view on the Pope and Claude: Leo XIV’s encyclical on AI is right to put humanity first. Навёл на этот сюжет Павел Конотопов, спасибо.

Кратко — здесь: Энциклика Льва XIV: ИИ на службе человечеству, а не горстке властителей — тоже на официальной странице Vatican News.

Сообщество ревностно следит и за высказываниями Линуса Торвальдса. Он — даже говорят некоторые — «переобулся». Но, вроде, вполне плавно подкорректировал свою позицию по поводу ИИ. Ещё вот здесь, в Why Linux creator Linus Torvalds gets angry hearing “99% of code is AI” на The New Stack, он остроумно высказался:

Меня натурально бесит, когда люди говорят: «99% нашего кода написано ИИ». А я могу гарантировать: 100% их кода написано компиляторами. Но об этом они помалкивают.

Он подчеркнул там 2 вещи:

  1. ИИ — не творец, а инструмент в руках человека‑творца.

  2. Социальная роль проекта важна, но она лишь побочный эффект, а не цель. Мы тут не воины света (social warrior). Проект таким никогда не был и никогда не будет.

Вот его слова буквально:

Sure, the social angle of working on open source is important and often a very motivating part of the project, but in the end that's a side benefit, not the point of the project. This is NOT some kind of “social warrior” project, never has been, and never will be.

Social (Justice) Warrior — это не слишком почтительный мем в адрес ультра‑активистской деятельности в англоязычном контексте. Так что это почти политическое высказывание.

Сэм Альтман вообще объявил: сингулярность не то что «при дверех», оно уже с нами. Это в подкасте Relentless 25 июля. Но следует просмотреть хотя бы по диагонали его манифест годовалой давности в собственном блоге: The Gentle Singularity.

<...>, это не <...> ИИ‑система, которая полностью автономно обновляет собственный код, но тем не менее это зародышевая форма рекурсивного самосовершенствования«.»

И там ещё есть про рекурсию. Есть и про высокопроизводительные BCI (brain‑computer interfaces), и даже про энергетическую стоимость 1 запроса:

Людей часто интересует, сколько энергии тратит запрос к ChatGPT; в среднем один запрос расходует около 0,34 ватт‑часа — примерно столько же, сколько духовка за чуть больше одной секунды, или энергосберегающая лампа за пару минут. Кроме того, на него уходит около 0,000085 галлона воды — примерно одна пятнадцатая чайной ложки.

Но самое интересное, как мне кажется, это его видение стартапов будущего:

Долгое время технические специалисты в стартап‑индустрии посмеивались над «людьми с идеями» — теми, у кого была только идея, и кто искал команду, чтобы её реализовать. Теперь мне кажется, что у них вот‑вот настанет звёздный час.

Пришла в голову идея — тут же реализовал. Пришла другая, лучше — реализовал и её.

Стоунбрейкер и юбилеи Postgres

Ура! 8 июля Postgres‑мир отпраздновал 30-летие любимой СУБД. Опубликован перевод фундаментальной статьи Майкла Стоунбрейкера The Design Of Postgres Storage System:

Проектирование системы хранения POSTGRES

А в день рождения PostgreSQL опубликовали перевод статьи, которая послужила основой этой СУБД. У неё тоже был юбилей — 40 лет с момента выхода:

Проектирование POSTGRES: как задумывалась популярная СУБД — Майкл Стоунбрейкер и Лоуренс Роу (Michael Stonebraker and Lawrence A. Rowe, оригинал статьи: The Design Of Postgres.

Сейчас считается так: 8 июля у PostgreSQL юбилей — 30 лет. В 1996 году Марк Фурнье (Mark 'scrappy' Fournier) из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres (до этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли).

Но есть мнение: Postgres — 40-летний, а не 30-летний. Со дня опубликования концепции. Концепция по латыни = зачатие. А вот в некоторых культурах возраст человека отсчитывают не с момента рождения, а с момента зачатия. Знаю, что так у корейцев и у калмыков. Наверняка и у многих других.

Отраслевая пресса не забыла об имениннике и отце именинника: вот, например:

Turing Award Winner: Disagreeing with Google, Postgres, Future Problems — часовая беседа с Маклом Стоунбрейкером. Как проект начинался, что не так в базах у Google и Amazon, что пора строить в будущем.

Образование

Вышли курсы PGPRO. Возможности Postgres Pro Enterprise 16. До этого курсы были по 13-й версии. Предварительные знания:

  • знакомство с ОС Unix;

  • уверенное владение SQL (знакомство с PL/pgSQL не обязательно, но полезно);

  • PostgreSQL в объеме курсов DBA1, DBA2, DBA3 и QPT, либо DEV1, DEV2 и QPT.

Учебные материалы есть по 22 темам, их список есть на странице курсов. Изменения по сравнению с предыдущей версией курсов существенные:

  • добавлены темы "Postgres Pro Enterprise Manager", "Миграция", "Перепланирование", "Сохранение планов запросов", "Защищенная схема", "Анонимизация данных", "Кластер BiHA";

  • многие темы предыдущей версии значительно расширены;

  • появились дополнительные практические задания;

  • курс стал четырёхдневным.

Курс обновили Игорь Гнатюк, Алексей Береснев, Павел Толмачёв, Илья Баштанов и Егор Рогов. Переходный тест для преподавателей можно будет проходить с 17 августа.

Open Alliance for PostgreSQL Education.

Появился на днях. Он будет сертифицировать специалистов по PostgreSQL. Открытый — это значит, что он будет привязан не к одной компании, а к целому списку участников альянса.

Об этой инициативе пишет на Medium Корнелия Биачич (Cornelia Biacsics) в Building the OAPE PostgreSQL Certification.

Куда идёт виртуализация

Честный разговор: от классической виртуализации до KubeVirt — видео онлайн от «Флант»

В подкасте участвовали:

  • Андрей Коновалов, независимый эксперт по виртуализации;

  • Дмитрий Горохов, директор направления виртуализации, «Инфосистемы Джет»;

  • Георгий Дауман, директор продуктового направления «Виртуализация», «Флант».

Обсудили:

  • как изменился рынок виртуализации в России и чего сегодня ждут заказчики;

  • чем классическая виртуализация отличается от подхода на базе KubeVirt и DVP;

  • как устроены установка, управление, автоматизация и интеграция с инфраструктурой;

  • что важно учитывать при работе с хранилищами, сетью, отказоустойчивостью и резервным копированием;

  • в каких сценариях DVP может быть особенно полезна, а где
    стоит учитывать ограничения;

  • почему не всегда достаточно просто взять открытый проект и развернуть его самостоятельно.

Конференции: Непал

И опять напоминаем об этой красивой во всех отношениях конференции:

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.

На этом пока всё.