Бета 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, проходящий все регрессионные тесты.
На сайте Майкл публикует новости своего проекта. Обратите внимание на тайминг:
-
20 апреля: pgrust: Rebuilding Postgres in Rust with AI: 2 недели назад [=6 апреля] я [в смысле Майкл] начал этот проект. Сейчас [20-го] в нём 450К строк кода.
-
28 апреля: pgrust update: at 67% Postgres compatibility, and accelerating.
-
26 мая: О четырёх всадниках апокалипсиса, 96% тестов: The four horsemen behind thousands of Postgres outages
-
25 июня: pgrust passes 100% of the Postgres regression tests.
-
16 июля: Три тупика: Postgres in Rust: three dead ends before we passed 100% of the regression suite.
Сразу приведём здесь ресурсы самого Майкла:
-
Попробовать можно на pgrust.com (WASM‑демо в браузере).
-
Туса на Discord.
-
Есть и mailing list.
Переписывал он на Rust не один. Во‑первых, вместе с Opus, щедро заплатив ему $100k. Ещё и транслятор c2rust использовали. Но Майкл и сам не ленив: он участвует в AoC (Advent of Code), мы об этом писали в номере Postgresso № 6 (55).
Кроме того он делал проект ещё и вместе с вполне кожаным другом — Джейсоном Зайбелем (Jason Seibel).
Им мало просто переписать весь Postgres для спортивного интереса. Они искренне хотят его улучшить.
В статье о Всадниках Апокалипсиса Майкл ругается на:
-
Вакуум и Wraparound — это понятно, все ругаются. Майкл думает начать с 64-битных Xid и задумывается о других TAM (Table Access Methods — о том, что с ними творится последнее время, мы писали в Postgresso #5).
-
Маловато соединений держит, и слабый параллелизм в исполнении запросов. Майкл вместе с Rust переходит на треды вместо процессов.
-
Плохие планы запросов — обычно Postgres выбирает правильные алгоритмы, но если ошибается, то ошибается ооочень сильно — считает Майкл. Он собирается научить pgrest разумно действовать в таких случаях.
-
Это, на мой вкус, самый неожиданный пункт: 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. треды
В сообществе на тредах отнюдь не поставили крест. Тредов пока нет, но их не только обсуждают, но и делают понемногу. Хотя в их необходимости сомневаются авторитетные люди. Сначала немного ликбеза:
Бен Дикен (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 вещи:
-
ИИ — не творец, а инструмент в руках человека‑творца.
-
Социальная роль проекта важна, но она лишь побочный эффект, а не цель. Мы тут не воины света (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. Продолжительность: 4 дня. Предварительные знания:
-
знакомство с ОС Unix;
-
уверенное владение SQL (знакомство с PL/pgSQL не обязательно, но полезно);
-
PostgreSQL в объеме курсов DBA1, DBA2, DBA3 и QPT, либо DEV1, DEV2 и QPT.
Учебные материалы есть по 22 темам, их список есть на странице курсов.
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.
На этом пока всё.
Автор: Igor_Le
