- Регистрация
- 23 Август 2023
- Сообщения
- 2 942
- Лучшие ответы
- 0
- Реакции
- 0
- Баллы
- 51
Offline

PostgreSQL 18
Всё, уже официальная версия.
Загрузить,
замечания к выпуску (release notes),
для прессы,
безопасность,
версионная политика,
контакты,
дайте денег.
Как всегда, все основные особенности обсудили ещё задолго до официальной, начав с первых бет (мы, например, говорили о некоторых статьях на эту тему ещё в номере Postgresso 3-4 за 2025, когда вышла самая 1-я бета).
Вот что подчёркивают в официальном релизе:
Подсистема асинхронного ввода-вывода (AIO), способствующая повышению производительности последовательных сканирований, сканирований по битовой карте (bitmap heap scans), VACUUM и других операций.
Теперь команда pg_upgrade сохраняет статистику оптимизатора.
Поддержка skip scan, позволяющего использовать многостолбцовые индексы B-деревьев в большем количестве случаев.
Функция uuidv7() для генерации UUID, упорядоченных по временным меткам (timestamp-ordered).
Виртуальные вычисляемые столбцы, значения которых рассчитываются во время чтения. Этот режим теперь установлен по умолчанию для всех генерируемых столбцов.
Поддержка аутентификации OAuth.
Доступность значений OLD и NEW в предложениях RETURNING команд INSERT, UPDATE, DELETE и MERGE.
Темпоральные ограничения (ограничения диапазонов) для ограничений PRIMARY KEY, UNIQUE и FOREIGN KEY.
Русский перевод уже появился на сайте.
Не всё шло гладко, в 3-й бете, например, были устранены 3 уязвимости:
PostgreSQL: PostgreSQL 17.6, 16.10, 15.14, 14.19, 13.22 и 18 Beta 3
CVE-2025-8713 - статистика оптимизатора позволяет читать данные внутри представления, секции или дочерней таблицы;
CVE-2025-8714: - можно было внедрить и исполнить зловредный код, используя pg_dump и запущенный psql клиента.
CVE-2025-8715: - некорректная нейтрализация символов новой строки при работе pg_dump.
Но устранение дыр - обычное дело.
На эту тему, как обычно в таких случаях, появилось вот что:
PostgreSQL 18: Часть 5 или Коммитфест 2025-03
Аналитическая статья-обзор Павла Лузанова получилась большая. Предыдущие 4 серии: 2025-01, 2024-11, 2024-09 и 2024-07, а вот соответствующие этим 5 английские переводы: 2025-03, 2024-07, 2024-09, 2024-11 и 2025-01. В этой разобраны 56 пунктов:
Клиентские и серверные - 12.
Мониторинг - 10.
Производительность -7.
Процедурные языки - 1.
Репликация - 3.
Безопасность - 6
Сервер - 13.
Команды SQL и встроенные функции - 4.
И по каждому пункту примеры! Например, в пункте про NUMA упоминаются функции и представления:
SELECT pg_numa_available();
SELECT * FROM pg_shmem_allocations_numa LIMIT 3;
CREATE EXTENSION pg_buffercache;SELECT * FROM pg_buffercache_numa LIMIT 3;
Так и до Гиннеса недалеко.
Параллельно Павел записывает доклады на ту же тему. Доклад PostgreSQL 18 был ещё в конце марта, на PGConf.Russia 2025, за неделю до "заморозки" нового.
А вот этот сделан был по свежим следам, точнее практически синхронно с релизом: rutube, vkvideo, dzen, youtube.
Компании-разработчики не пропустили возможность высказаться по поводу новой версии:
EDB празднуют:
Celebrating the PostgreSQL 18 Release. Но не только празднуют:
Вышла серия Preview PostgreSQL 18’s OAuth2 Authentication, автор Гуань И Си (видимо - Guang Yi Xu):
Explore How it Works.
Building a Custom OAuth2 Validator by Rust.
Enhancing a PostgreSQL Client Library to Speak OAUTHBEARER.
А Джейоб Чемпион (Jacob Champion) добавляет:
Но сделали ещё и видео по этой теме:
OAuth, testing, and the path from prototype to release.
Ещё есть видео на тему Inside the Release Cycle and the Power of Community Contribution.
Питер Айзентраут (Peter Eisentraut) пишет:
Альваро Эррера (Álvaro Herrera) пишет о
Crunchy Data уже не Crunchy, но статьи публикует:
Get Excited About Postgres 18 - Элизабет Кристенсен (Elizabeth Garrett Christensen) хоть и не празднует, как в EDB, но делится своим воодушевлением.
OLD and NEW Rows in the RETURNING Clause - автор Брандур Лич (Brandur Leach).
От CYBERTEC пишет её глава Ханс-Юрген Шёниг (Hans-Jürgen Schönig):
PostgreSQL 18 and beyond: From AIO to Direct IO?
PostgreSQL 18: Better I/O performance with AIO
PostgreSQL: "UPDATE … RETURNING" made even better
Fujitsu представляет Амит Капила (Amit Kapila):
А Microsoft - Томаш Вондра (Tomas Vondra):
А Stormatics - Умейр Шахид (Umair Shahid):
3 Features I am Looking Forward to in PostgreSQL 18 (2025-09-09) - / Stormatics
Тудор Голубенко (Tudor Golubenco), техдир компании Xata:
Going down the rabbit hole of Postgres 18 features (2025-09-29) - / xata
И, наконец (not least), интересную тему разрабатывает французский фрилансер Даниэль Веритэ (Daniel Vérité - то есть Даниэль Истина):
Что делать, если патч не приняли?
Интересная была переписка по этой теме в рассылке hackers. Ответы будут полезны многим.
Речь об этом патче: Improve the performance of Unicode Normalization Forms
Но вопрос шире: Что делать?
Автор патча, Александр Борисов (Alexander Borisov, lexborisov), пишет:
Я здесь новичок, поэтому, пожалуйста, посоветуйте: если патч не был принят на коммитфесте, значит ли это, что он не нужен (никому не интересен), или просто не хватило времени? Стоит ли мне переносить это на следующий commitfest?
Я вижу, что патчи часто переносятся с одного коммитфеста на другой. Я правильно понимаю, что это нормальная практика? Пожалуйста, поймите меня, не всё здесь прозрачно, подход не очевиден. Как мне быть? Спасибо!
Дэвид Джонстон (David G. Johnston) ответил:
Если вы чувствуете, что патч может пройти (committable), пусть остаётся в нечерновом коммитфесте, перемещаясь каждый месяц или около того, пока его не закоммитят.
Том Лейн (Tom Lane) ответил более пространно:
На самом деле это довольно трудно понять — у нас в очереди много патчей и явно недостаточно ревьюеров. Возможно, кто-то дойдет до него со временем, а может быть, действительно никто не заинтересован в этой конкретной теме (но в исправлении ошибок и в улучшении производительности почти всегда кто-то заинтересован). Сохраняйте оптимизм: пока вы верите, что патч стоит того, продолжайте продвигать его на следующий коммитфест. Раньше мы делали это автоматически, но теперь просим авторов делать это самим, чтобы пропалывать патчи, которые авторы забросили.
Александр Борисов не ограничивается благодарностью, он новичок только здесь:
Я всегда выбираю оптимизм. Я уже давно в open source, а такой подход вижу впервые. У меня есть план по дальнейшему улучшению производительности Postgres в части Unicode (и не только), а это своего рода основа для работы с текстом. Я не хочу перегружать сообщество патчами. Я подхожу к этому системно. Еще раз спасибо, Том. Подход сообщества стал для меня яснее.
Но когда ты работаешь в компании, которая отсылает патчи систематически, к этому процессу в компании и стараются подходить соответственно - систематически. Вот что пишет, например, Флоор Дреес (Floor Drees) из EDB:
PostgreSQL Contributions: Onboarding New Developers in Barcelona
Пишет она не о себе, а о коллеге Эндрю Данстане (Andrew Dunstan), который запустил программу помощи желающих стать контрибьюторами. Для этого их в середине сентября на 3 дня вывезли в Барселону. Там они практиковались, ревьюили патчи друг друга, писали документацию, а в конце Эндрю дал им реальную задачу, которая прописана в переписке hackers: Retail DDL.
Учил он их уму-разуму не один. Среди учителей хорошо знакомый нам Альваро Эррера (Álvaro Herrera, в сообществе уже 24 года), учил дебажить код. Называется эта программа Postgres Developer U.
Напомним, что при каждом официальном релизе появляется такая страничка:
Благодарности
Ну а те, кто уже успешно постит патчи в сообщество? Им дадут PostgreSQL-медальки. В объявлении о выходе версии огромный список - благодарят <?> человек. В том числе 43 сотрудника Postgres Professional. Специальной программы в компании нет, про учёбу в Барселоне сведений нет, но написание патчей всячески приветствуется и стимулируется.
Вот эти угловые скобочки не опечатка, не забыл убрать, а повод для крохотного исследования. Я решил скормить список на страничке Благодарностей разным ИИ/LLM, предложив им пересчитать.
Результаты скромной просьбы "посчитай сколько разработчиков в списке Acknowledgments на странице https://www.postgresql.org/docs/18/release-18.html#RELEASE-18-ACKNOWLEDGEMENTS":
GigaChat (Сбер): 672
Богато! Попросил проанализировать, сколько в этом списке сотрудников Postgres Professional. Гига начал генерить список с тысячами непонятно откуда взявшихся фамилий, но потом одумался и сказал, что произошла досадная ошибка.
perplexity: 431
Скромно. По 2-му вопросу сказал, что в списке имен порядка 30-50 сотрудников Postgres Professional, исходя из совпадений с публичными командами и авторами патчей.
Если нужно, могу помочь составить список из Acknowledgments, потенциально связанных с Postgres Professional, исходя из известных имён.
Браво. А конкретней?
В список от perplexity попало руководство компании, некоторые правильные фамилии с правильным спеллингом, но и бывшие сотрудники, и с кривым спеллингом, например:
"Александр Кузьминков" (Alexander Kuzmenkov) сейчас сотрудник Neon;
"Максим Коротов" (Maksim Korotkov) - он, вообще-то, Александр, разработчик OrioleDB, теперь в составе Supabase;
а также те, кто в компании никогда не работали, например:
Андрей Боролин (Andrey Borodin), работает в Яндекс.Облако.
Алиса: 645
Известно, что в разработке PostgreSQL 18 приняло участие более 40 сотрудников компании Postgres Professional, которые внесли по меньшей мере 140 коммитов.
На самом деле: 507 и 43
Открытия
В этом случае не научные открытия, а вот что:
OrioleDB Patent: now freely available to the Postgres community
Это официальное заявление Пола Копплстоуна (Paul Copplestone), сооснователя и гендира Supabase, которая год назад приобрела OrioleDB. Он пишет: наш зарегистрированный патент это щит, а не меч, мы только хотим защитить им пользователей open source от хищников.
Интересно, что в сети патент покритиковали, и юристы компании, как и обещал критикам сам Пол, быстро подкорректировали. Сейчас это лицензия типа Apache 2.0, похожая на лицензию PostgreSQL, но в ориолевской явно прописано, что все пользователи OrioleDB автоматически становятся обладателями неисключительной лицензии на Надёжные многоверсионные B+-деревья (Durable multiversion B+-tree). Причём это относится и к будущим коммерческим форкам.
Планы Supabase такие:
Разрабатывать OrioleDB как заменяемый механизм хранения (drop-in storage engine) для работы с Postgres через Table Access Method API.
Работать вместе с сообществом над минимизацией требуемых изменений в ядре и внесением патчей в ядро Postgres от сообщества, чтобы в результате можно было запускать OrioleDB как расширение.
Ещё вот какая новость:
pgEdge goes Open Source
pgEdge - энтерпрайзный дистрибутив Postgres с фокусом на высокой доступности и распределённости, может работать в режиме мультимастера. Раньше это был коммерческий продукт с “source available”, доступным кодом, но не open source. Теперь он под лицензией PostgreSQL, одобренной OSI.
Любопытна информация о том, кто это рассказывает. Это Дейв Пейдж (Dave Page), он сейчас вице-президент по разработкам pgEdge. Участник основной команды Postgres и создатель pgAdmin, с более чем 25-летним опытом разработки Postgres. Секретарь PostgreSQL Europe и председатель PostgreSQL Community Association. Ранее занимал должности вице-президента и главного архитектора по инфраструктуре баз данных в EDB.
И вот его откровения:
В ноябре прошлого года, после почти двух десятилетий работы на моём предыдущем месте, я понял, что не хочу работать в компании, которая быстро становится ориентированной на искусственный интеллект. Я перешёл в pgEdge, где внимание и усилия сосредоточены на распределённом PostgreSQL.
Заодно:
Why We No Longer Lock Premium Features - Neon
HIPAA, SLAs, SOC 2 и экспорт логов теперь доступны всем по ценам, пропорциональным использованию, по схеме 'pay as you go'.
Автор статьи, Моника Стейнке (Monica Steinke, технический менеджер продукта), между делом разоблачает "Ловушку традиционных уровней ценообразования для баз данных" неоновских конкурентов.
Экзотические постгресы и не постгресы
Deep.Foundation
Что-то экзотическое из Будущего. Соответственно - туманное:
Представьте себе абстрактное пространство, в котором вначале возможны только действия со ссылками. С Deep.Case вы можете погрузиться в данные так, как будто это продолжение ваших собственных мыслей. Расставляйте ваши якоря ссылок и настраивайте их поведение. Deep.Case может использоваться аналитиками как рабочее пространство для данных или как пространство для сборки. Также возможны управление проектами и мониторинг статуса . Это расширяемая среда, построенная на d3/threejs/AFrame.
Сквозь маркетинговый туман этого стартапа проступают некоторые контуры: известно, что подо всем этим PostgreSQL для хранения связей и Hasura для работы с графами. В статье Стартап с другой планеты есть сильное утверждение об архитектуре проекта: единственный API доступа - доступ к CRUD операциям над связями.
И ИИ там в полный рост, естественно.
Ассоциативные связи и Фактор рефакторинга - о них пишет гендир стартапа Иван Сергеевич Глазунов aka IvanSGlazunov - Апостол Глубины ни много ни мало (это нормально: это же Deep Foundation). Вот документация. Кроме Апостола в команде ещё 6 человек. У них есть имена, фамилий нет.
А замыкают эту серию Хроники безумного стартапа. День 581.
SurrealDB
Признаемся: самое экзотическое в этой базе - её название: ну как можно пройти мимо такого. Но и необычного там немало. Цель: сделать базу, которая бы быстро и надёжно работала и с SQL, и с GraphQL, при этом соблюдая ACID.
Я знаю, что за этим проектом с интересом следят люди из мира ИИ. Пока слегка поругивают, но ждут - что дальше. Сейчас реализовано 1-нодовое хранение in-memory, в бете SurrealKV с собственным хранилищем на Rust, пишущие и читающие запросы распараллелены, версионированные запросы к графам. И, конечно, о векторах они не забыли. А в будущем SurrealKV будет много-нодовым.
Гитхаб здесь. Интересно, что почти ничего ещё не доделав, компания уже позаботилась о читателях:
Документация.
Свой университет: SurrealDB University.
Интерактивная книжка о Сюрреалистическом Ренессансе: Aeon's Surreal Renaissance.
А в этой статье есть список векторных баз, и Сюрреалистическая База туда попала:
Новые векторные СУБД и другие инструменты для эмбеддингов и RAG
В этом контексте, быть может, не лишним будет глянуть труды классиков. Например, вот это:
Readings in Database Systems, 5th Edition - это Red Book, где статьи классиков Майкла Стоунбрейкера, Джо Хеллерстайна (Joe Hellerstein), Питера Бейлиса (Peter Bailis) на такие, например, темы: Large-Scale Dataflow Engines.
Железо будущего
Дезагрегация серверов и ее причины
Футуристичный ликбез Тедвайзера. Речь о ЦОДах будущего - надалёкого, похоже. Серверы отомрут - это слишком крупнозернистая структура. Объединять будут не серверы, не лезвия, не материнские платы, а сразу чипы - будет структура мелкозернистая. Получится должен единый пул процессоров, пул памяти и пул СХД.
Для реализации мелкозернистых планов потребуются скорости каналов между процессорами и памятью 500-800 Гбит/сек на расстоянии до 1 метра, а между процессорами и периферией — 100-200 Гбит/сек на расстоянии 5-100 метров.
Статьи
Восстановление повреждённых данных в PostgreSQL
Евгений Бредня aka bzq пишет об экстремальных ситуациях - когда сам Postgres данные прочитать уже не может.
"Статья написана по мотивам моего выступления на конференции PGConf.Russia в 2023 году. Только сейчас дошли руки её написать, хотя в планах подготовка статьи была изначально. Могу сказать, что в плане восстановления данных за эти годы ничего не поменялось, вся информация актуальна в 2025 году, да и дальше тоже."
Главное, конечно, диагностика. Евгений использует команды Linux, perf и flamegrapg. А ещё и делится собственными функциями, например, molotilka(), она написана на PL/pgSQL, всегда доступной в Postgres.

Этой трогательной картинкой Евгений иллюстрирует восстановление данных
Перед тем как рассказать о нюансах восстановления (это объёмный и конкретный материал), Евгений честно предупреждает:
Важно оценить целесообразность проведения работ. Если восстановительные работы займут годы, или качество восстановленных данных не позволит их использовать, то нет смысла терять столько времени и сил. Будьте реалистами. Может быть всё же имеющаяся старая копия базы будет полезнее непредсказуемых результатов восстановления? Особенно с учётом того, что даже оценить полноту восстановленных данных часто затруднительно, не говоря уже об их логической целостности. Приемлемые результаты будут только в случае очень ограниченного характера повреждений.
PostgreSQL maintenance without superuser
В блоге со "скучным" названием boringSQL Радим Марек (Radim Marek) пишет о встроенных, заранее определённых ролях, которые позволяют вести многие важные работы по поддержанию БД и при этом не требуют доступа суперюзера. Таких он насчитал 16 в разделах:
доступ к данным (3);
обслуживание и диагностика (4);
ОС (4);
Файловая система (3);
Особые случаи (2).
Радим не только объясняет какая роль для чего, но и даёт исторический экскурс в эволюцию ролей от версии к версии. Далее говорит об особой роли pg_database_owner, которая теперь представляет владельца текущей базы данных
Postgres Internals Deep Dive: Process Architecture
В блоге EDB Сринат Редди (Srinath Reddy) действительно ныряет в более низкие уровни, чем обычно рассматриваются в статьях. ServerLoop (The Loop of Life), переодевание фоновых процессов (The disguised Backend process), процесс-жнец (TheReaper - не путать с Ripper - Джек Потрошитель).
Shardman и Citus: как масштабировать СУБД Postgres Pro
В статье, подписанной Мила aka melanny20 (Редактор Postgres Professional), честно рассказывается о важных вещах, о том, какому кесарю кесарево, где пересекаются, а где нет возможности Shardman и Citus. Об особенностях шардирования, отказоустойчивости, об архитектурах репликации.
А Дмитрий Урсегов aka fdmitry в Postgres Pro Shardman: горизонтальное масштабирование реляционных СУБД пишет только о Шардмане, которым сам занимается. Но начинает с истории шардирования в PostgreSQL, глобальном DDL, о том, как случилось, что шардировании = секционирование + FDW. О мультиплексоре, без которого такая архитектура загрустила бы.
Пузомерки
PostgreSQL — СУБД №1 по результатам опроса Stack Overflow
Stack Overflow опубликовала результаты ежегодного опроса среди более чем 26 тысяч разработчиков: PostgreSQL 2-й год 1-я среди СУБД. В 2025 году за неё проголосовали 55,6% - на 11% больше, чем в прошлом году. Увеличился разрыв с MySQL, который расширился с 8 до 15 процентных пунктов. Дальше SQLite.
Кроме того, PostgreSQL стала самой желанной (46,5%) и самой уважаемой (65,5%) СУБД в категории Desired & Admired.
Обучение и олимпиады
Postgres Professional releases DBA course in English
Популярный в России курс DBA1, который разрабатывают и обновляют мои коллеги, вышел на английском языке. Сейчас доступны 3 курса на английском:
Introduction to PostgreSQL (2-дневный).
DBA1. Basic PostgreSQL Administration (3-дневный).
DEV1. Basic Server-Side Application Development (4-дневный).
Будут появляться и другие. Что до русских курсов, то они неуклонно обновляются:
Летняя школа Postgres Professional 2025: теперь для студентов со всей России
25 студентов получили стипендии после прохождения Летней Школы Postgres Professional в Новосибирске (в Летней школе при НГУ). На этот раз участие смогли принять не только студенты из региона, а ребята со всей России, им организовали трансфер и проживание на время учебы: 5 регионов, более 30 лекций, 4 недели учебы.
Акселерационная программа «Бизнес-инноваторы: Алтай-Азия»
С 12.09.2025 по 12.12.2025 в ФГБОУ ВО «Алтайский государственный университет» в рамках реализации федерального проекта «Технологии» проходит акселерационная программа «Бизнес-инноваторы: Алтай-Азия». В АлтГУ в 2024 создали более 70 технологических и креативных стартапов.
Конференции
PGConf.СПб 2025
Прошла 29 сентября при прекрасной погоде. Я пожалел, что не взял чёрные очки, а взял зонтик - следуя стереотипам. Проходила в Конгресс-центре гостиницы "Санкт-Петербург" - прямо напротив небезызвестной Авроры.
Не такая большая конференция, как московская, но солидная: более тысячи участников онлайн и офлайн, 42 доклада в 3 потока, 7 мастер-классов, 8 стендов с решениями на базе PostgreSQL и Postgres Pro. Прямо на конференции можно было пройти сертификацию.
Постараемся попозже написать подробней. Сейчас отмечу доклад коллеги Егора Рогова о новой демобазе: предыдущая версия появилась целых 8 лет назад, в новой версии много интересного, но самое - это, конечно, генератор. С его помощью можно создать собственную демобазу с городами и перелетами, причем любого размера.
Скажу 2 слова о докладе, на котором не был: в это время в большом зале Павел Лузанов рассказывал о Новом в PostgreSQL 18 - как такой пропустишь. Два слова будут поэтому не о самом докладе - Как просто настраивать параметры сложных типов, а докладчике: Антоне Чумаке, студенте 4-го курса Факультета информационных технологий НГУ. Он же - младший специалист в департаменте разработки продуктов Postgres Professional. Но само интересное ИМХО (да простит мне читатель эту старинную аббревиатуру): Постгресом Антон занимается всего полгода. Это я подслушал на конференции. Вот что такое хорошее образование! Впечатляет!
Я, кстати, тоже делал там доклад, но этакий ... гуманитарный: Профессиональные философы и «философы» об open source.
PG.Academy 2025
Сенсация: Павел Лузанов не открывал конференцию докладом о новом в PostgreSQL. Отнюдь. Его доклад представлял собой Путеводитель по документации. Но не только. В конце доклада Павел не постеснялся при всём честном народе отослать в сообщество сообщение об ошибке в документации.
С конференцией PGConf.СПб эту конференцию сближает не только время проведения (6 октября), но и обилие питерских участников. Однако, не только представители 2 столиц докладывали и слушали. География довольно обширная. Вот, например, доклад Обобщение опыта проведения занятий по разработке API-приложений на основе реляционной СУБД Ольги Половиковой из Алтайского государственного университета.
А что особенно отличает эту конференцию от аналогичной прошлогодней - так это место проведения: Центр Культур ВШЭ на Покровском бульваре. Место менее экзотичное, чем затягивающийся новыми корпусами пустырь между Мичуринским и Вернадского, но - чего уж там - добираться проще.
Postgres Ibiza 2025
Вот-вот начнётся: 15-17 октября. В прошлом году всё прошло недурно, судя по впечатлениям Хесуса Эспино (Jesús Espino): My experience at PGIbz 2024.
PGConf India, 2026
Пройдёт 11-13 марта. Доклады ещё принимаются. Но скоро не будут: до 15 октября.
Nordic PGDay 2026
Должна состояться 24 марта в Хельсинки. Это однодневка и однотрековка. Главная цель - собрать постгресистов скандинавского региона.
На этом пока всё.