PostgreSQL 19 Beta 3

А также 18.6, 17.11, 16.15, 15.19 и 14.24. В этой бете и серии минорных версий закрыли 28 дыр, из них 14 с рейтингом опасности 8.8 по CVSS v3.1 и ещё по одной 8.2 и 8.1. То есть очень опасные. Не 28 в сумме по всем версиям, а каждая версия затронута. Уязвимости самые разные в самых разных местах. Есть, например, дыра, связанная с tsvector и tsquery.

До этого сенсацией были 11 дыр в 18.4 и её сёстрах. В Postgresso #4 (89) мы посвятили этому раздел Минорный релиз. Заплатки, принцессы, призраки. Потому, что это не просто всплеск статистики, это было, конечно, связано с новыми ИИ‑инструментами. Здесь тоже можно встретить «спасибо AntAISecurityLab / Codex Security компании OpenAI / OpenAI Security Research Team / TrendAI Zero Day Initiative». Но раньше ИИ‑инструменты использовали в основном китайские стартапы, теперь же PostgreSQL благодарит Эми Бернетт (Amy Burnett) вместе с Codex Security компании OpenAI за сообщение об этой проблеме. И вообще звучат имена с самой разной национальной фонетикой. В списке благодаримых и привычные, например, Мелани Плейгман (Melanie Plageman), Андрес Фройнд (Andres Freund), рядом с ними упоминания ИИ нет. Значит ли это по умолчанию, что ИИ‑инструментами они не пользовались? Не знаю.

Кроме того победили 110 багов. И такая скорость закрытия дыр связана тоже — наверняка — с новыми ИИ‑инструментами.

Что же с российскими форками? Мне, по крайней мере, известно, что уже вышли экстренные Postgres Pro Enterprise «нулёвки»: 18.6.0, 17.11.0, 16.15.0, 15.19.0 и 14.24.0. 14-я вышла ещё 14-го числа, 18-я не поленилась выйти в ночь на субботу 22-го.

Заплатки в 18.4 тогда вызвали тогда более бурную реакцию, но и сейчас несколько статей появилось:

PostgreSQL fixes 28 CVEs, including multiple code‑execution paths

Статья подробно разбирает, какие именно классы уязвимостей были закрыты в ветках 18.6, 17.11, 16.15 и так далее, выделяет самые опасные векторы атак (включая RCE через pgcrypto и plperl) и даёт пошаговый план безопасного обновления для администраторов.

PostgreSQL ships 28 security fixes in one go

Разбор того, почему сообщество пошло на такой шаг, как выпуск 28 патчей безопасности одновременно в августе 2026 года, и как это влияет на стабильность версий 18.6 и 19 Beta 3.

Если поскрести графа

В Бете уже надёжно закрепилась реализация стандарта SQL/PGQ (SQL Property Graph Queries) — SQL‑совместимая часть языка GQL (Graph Query Language).

История того, как графовые языки запросов попадали в PostgreSQL, тесно связана с эволюцией стандартов и развитием расширений. В само ядро PostgreSQL попадает не отдельный самостоятельный язык GQL (Graph Query Language), а его часть — SQL/PGQ (SQL Property Graph Queries), который разрабатывался параллельно с GQL.

Изначально в статьях и обсуждениях 2024–2025 годов мелькала информация, что PGQ попадёт в PostgreSQL 18. Но тогда не получилось.

По поводу стандарта есть две статьи Петера Айзентраута (Peter Eisentraut). Во второй он проставляет статусы и версии, в которых появилась поддержка.

SQL:2023 is finished: Here is what’s new и

Postgres and SQL:2023: What's Supported?

Петер и разрабатывал этот патч, представив его ещё пару лет назад сообществу. К нему присоединился Ашутош Бапат (Ashutosh Bapat) — говорят, что именно он является автором большей части кода и архитектуры этой фичи. Таким образом и Microsoft поддержала графов — Ашутош их сотрудник.

Итак: что же с графами в PostgreSQL? Они теперь там. Но насколько эти графы настоящие, а не самозванные?

PostgreSQL 19 SQL/PGQ Property Graph Queries

В блоге Neon: Графы свойств определяются как представления поверх существующих реляционных таблиц. Данные остаются там, где были. Пользователь просто говорит PostgreSQL, какие таблицы представляют узлы, а какие — рёбра.

Автор создаёт для примера таблички в той области, где применение графов типично и желанно: строит крохотную соцсеть. А потом создаёт уже графовую табличку (указав VERTEX TABLES и EDGE TABLES) и, используя MATCH, спрашивает у графа: кто френды френдов и кто лайкал Алису.

Кроме того в статье показано, как сделать коктейль из PGQ и обычного SQL, и что у PGQ под капотом. А там никакой экзотики: спроси, мол, EXPLAIN и увидишь обычные узлы плана Postgres.

Ещё там есть матрица свойств Postgres PGQ, AGE и Neo4j. Да и Нет пока что разбросаны по этим колонкам довольно равномерно. Есть там и маленький списочек ссылок:

• Commit 2f094e7a: SQL Property Graph Queries (SQL/PGQ)

• PostgreSQL devel docs: CREATE PROPERTY GRAPH

• ISO/IEC 9075–16:2023 (SQL/PGQ)

Postgres Learns to Speak Graph: Inside SQL/PGQ and PostgreSQL 19

SQL/PGQ — это уровень запросов, а не движок графовой базы данных — пишет Надим Хан (Nadeem Khan), ведущий технический архитектор по Data Lakehouse с использованием Azure Synapse, Python и инструментов Azure. Статья в блоге CodeWithNK.

Всё это, — говорит он, — работает только на чтение: вы определяете и запрашиваете графовое представление поверх существующих таблиц, но вставку, обновление и удаление данных по‑прежнему выполняете с помощью обычного SQL. В нём нет встроенной библиотеки графовых алгоритмов: никаких нативных функций PageRank, обнаружения сообществ или поиска кратчайшего пути.

А на самом‑то деле там внутри старые добрые рекурсивные CTE.

PostgreSQL всегда умел «работать с графами» в том смысле, что любая реляционная база данных может моделировать узлы и рёбра в виде таблиц и обходить связи с помощью JOINов. Для обходов узлов типа «найти всех, кто находится в трёх рукопожатиях от этого человека» строили рекурсивные обобщённые табличные выражения (WITH RECURSIVE). Но в таких запросах легко ошибиться, их трудно читать, и они становятся неудобными, когда нужно добавить ветвление, обнаружение циклов или пути переменной длины. Рекурсивные CTE любят побаловать себя уходом в бесконечный цикл, воспользовавшись невнимательностью или неопытностью программиста. Последствия таких игрищ печальны.

SQL/PGQ создан просто для того, чтобы сделать этот класс запросов снова читаемым. SQL/PGQ позволяет объявить граф свойств (property graph) как слой метаданных поверх уже существующих таблиц. Он не вводит новый движок хранения и не требует миграции данных.

В этой статье Надим показывает синтаксис, а кроме того проводит границу между новеньким SQL/PGQ и стариной Apache AGE (openCypher). Автор раскладывает, в каких случаях лучше использовать SQL/PGQ, а когда все же стоит оставить AGE.

SQL/PGQ in Practice: GRAPH_TABLE on Oracle and PostgreSQL 19

Статья в блоге JamSQL. Автор берет стандарт SQL:2023 и запускает идентичные графовые паттерны на бета‑версии PostgreSQL 19 и на Oracle Database 23ai (которая тоже внедрила этот стандарт недавно, но он там уже не в статусе экспериментального). Статья показывает нюансы синтаксиса и разницу в работе оптимизаторов.

SQL/PGQ — 16-я часть стандарта SQL (ISO/IEC 9075–16:2023) — позволяет определить граф свойств поверх уже имеющихся у вас реляционных таблиц и выполнять запросы к нему с помощью наглядных паттернов вроде (a)‑[r]→(b) вместо рекурсивных CTE, написанных вручную. Сейчас этот язык поддерживают две СУБД: Oracle Database 23ai и более поздние версии (нативная поддержка, общедоступная версия, все редакции, включая бесплатную) и PostgreSQL. Разобран пример, есть параллельное сравнение того, чем отличаются диалекты каждой из них. Синтаксис рекурсивных CTE немного отличается. Заодно показывают, где лажа в реализации Node.js.

В статье есть матрица возможностей. В ней важнейшее отличие такое: в Oracle есть bounded quantifiers (ограниченные кванторы). Они задают строгие нижние и/или верхние границы длины пути. Использование таких кванторов считается безопасным, так как база данных может заранее оценить сложность запроса и избежать бесконечных циклов или взрывного роста потребления памяти. Bounded quantifiers бывавют {n} / {n,m} / {,m}.

{n} — это ровно n переходов (ребер), {n,m} — от n до m переходов включительно и{,m} (или {0,m}) — от 0 до m переходов включительно.

В Postgres пока что число переходов фиксированное. А вот unbounded quantifiers (неограниченных кванторов), которые задают нижнюю границу, но не задают верхнего предела длины пути, нет ни там, ни здесь. Но что‑то ещё наверняка появится.

У графов есть планы на будущее. И о них можно узнать, скорее, не из статей, а из обсуждения на специальном ивенте — PGConf.dev 2026 Graph Database Developer Meeting. Но об этом ниже, во второй части этого раздела. А пока траектории:

Траектории ч.I

Элизабет Гарретт Кристенсен (Elizabeth Garrett Christensen, developer advocate — каких только титулов не напридумывают) с графами обходятся по‑старинке:

Graph Queries Across Billions of Rows of Scattered Data with Postgres and Apache AGE

Это статья в корпоративном блоге Снежинки. Элизабет рассказывает о расширении Apache AGE (= A Graph Extension) с графовым языком запросов openCypher. Есть, — говорит Элизабет, — и другие графовые базы — Neo4j, Amazon Neptune, TigerGraph — но внутри базы запускать такие запросы умеет только AGE. С такими расширениями, как pg_lake, мы получаем доступ к объектным хранилищам, где файлы лежат как csv, JSON, Apache Parquet и Apache Iceberg. Но возможность агрегировать эти данные — это другое.

Она сравнивает возможности AGE с CTE, но молчит о SQL/PGQ (SQL Property Graph Queries). Опубликована статья в конце мая. Тогда ещё беты 19-й версии не вышли, но были на подходе — бета 1 вышла в июне. Элизабет, разраб‑адвокатесса пишет вполне технологичные статьи иногда на довольно редкие технические темы:

Your COUNT(DISTINCT) Is Too Slow: Approximations and Sampling in Postgres

Но вот её статья на, так сказать, социальную часть её «адвокатской» работы:

Meet the Team Behind Snowflake Postgres

Это статья годовалой давности. И она о людях из Crunchy Data, которую Снежинка приобрела летом 2025. В статье много известных имён, немного истории этой замечательной компании, событий, поворотов стратегии. Отнюдь не все приобретатели коллективов так делают.

Элизабет рассказывает, как всё началось в 2012, об основателях Crunchy Data — это Боб и Пол Лоренсы (Bob & Paul Laurence) Bob and Paul Laurence, о Crunchy Certified PostgreSQL, как получили Common Criteria certification, о Postgres STIG, Postgres Operator for Kubernetes и Crunchy Bridge.

Но, главное, о личностях. Известнейших, а то и ключевых — как, например, сверхскоростной программист Том Лейн.

Основатели Боб и Пол Лоренс создали безопасный дистрибутив Crunchy Certified PostgreSQL, помогли ему получить сертификацию Common Criteria и написали официальное руководство по безопасности Postgres STIG. В 2017 году компания выпустила новаторский Postgres Operator для Kubernetes, а в 2020-м, адаптируясь к рынку облачных услуг, запустила Crunchy Bridge.

Ключевые фигуры Crunchy и их конкретный вклад в экосистему Postgres:

• Крейг Керстиенс (Craig Kerstiens): бывший директор по продукту Crunchy, помогал создавать Heroku Postgres, теперь возглавляет инженерное направление Snowflake Postgres.

• Элизабет Гарретт Кристенсен (Elizabeth Garrett Christensen): член Совета директоров Ассоциации PostgreSQL в США. Вот так, не только разраб‑адвокатесса.

• Том Лейн (Tom Lane): постоянный и сверхпроизводительный коммиттер ядра Postgres, работает в Crunchy с 2015 года.

• Пол Рэмзи (Paul Ramsey): возглавляет Руководящий комитет проекта PostGIS.

• Марко Слот (Marco Slot) и Ондер Калачи (Önder Kalaci): ключевые разработчики проектов pg_cron и Citus.

• Кит Фиск (Keith Fiske): ключевой контрибьютор расширения pg_partman для автоматизации секционирования таблиц.

• Грег Сабино Маллейн (Greg Sabino Mullane): добавил команду \timing в psql.

• Уилл Лейнвебер (Will Leinweber): добавил команду \watch в утилиту psql. Кажется, это единственный в этом списке, кто не попадал на страницы нашего Postgresso.

• Дэвид Кристенсен (David Christensen): добавил команду \conninfo в psql.

• Карен Джекс (Karen Jex): член Совета директоров PostgreSQL Europe. Ещё одна большая Postgres‑общественница.

Но прикупить коллектив разработчиков целиком — это одно дело, а совсем другое — собирать их с миру по нитке. Я бы назвал в числе первых собирателей вот эти 2 компании — это настоящие талантососы: PgEdge и ClickHouse.

Не устаю ухмыляться, читая о достижениях Дэйва Пейджа в PgEdge. Не потому, что они так себе, а вот почему:

«после почти двух десятилетий работы на моём предыдущем месте, я понял, что не хочу работать в компании, которая быстро становится ориентированной на искусственный интеллект. Я перешёл в pgEdge, где внимание и усилия сосредоточены на распределённом PostgreSQL.»

Это мы цитировали ещё в Postgresso 7–8 за 2025. Дэйв — участник Postgres Core Team, создатель pgAdmin, он — секретарь PostgreSQL Europe и председатель PostgreSQL Community Association. А «предыдущее место» — это, на минуточку, EDB, где он был вице‑президентом и главным архитектором по инфраструктуре баз данных.

А PgEdge официально себя теперь называет так: Компания‑разработчик Enterprise Postgres for Agentic AI.

Они уже предлагают, например pgEdge AI DBA Workbench. В ней традиционные средства мониторинга сочетаются с ИИшными.

Autovacuum Tweaks Coming to Postgres 19 — это статья Шона Томаса (Shaun Thomas). Известный, заслуженный постгресист, автор книги PostgreSQL High Availability Cookbook. Мы ещё помним его и по серии статей PG Phriday (мы переводили это как пятнецы), последняя, кажется, PG Phriday: Addressing Demands of Highly Available OLTP Environments — под крышей EDB (позже — помните? — идею подхватил Ryan Booz с его пятнечным блогом PGSQL Phriday — A monthly community blog event for the PostgreSQL community). И вот теперь Шон Томас в pgEdge.

Недавно талантливый странствующий программист Андрей Лепихов (Andrei 'danolivo' Lepikhov) тоже обосновался в pgEdge, пишет статьи уже в качестве их сотрудника.

Немного о новом проекте pgEdge:

ColdFront, бета‑версия.

ColdFront умеет хранить часть таблиц в обычном PostgreSQL, а холодные данные — в Apache Iceberg (в формате Parquet на S3-совместимом, Azure или GCS‑хранилище), причём холодный уровень доступен как для чтения, так и для записи через тот же SQL.

Есть два режима работы:

• Многоуровневый режим (Tiered mode) хранит свежие данные в нативных секциях PostgreSQL, а более старые данные архивирует в Iceberg по пороговому значению (watermark);

• Раздельный режим (Decoupled mode) хранит таблицу целиком в Iceberg, а PostgreSQL содержит лишь тонкую обёртку‑представление и регистрационную запись.

Второй талантосос — ClickHouse — скликает к себе не менее интересных постгресистов. Траектория компании не совсем прямая: они направление не меняли, но с 2009 по 2021 были внутри Яндекса. Проект возглавлял Алексей Миловидов (Alexey Milovidov). В 2016 они ушли в open‑source, а в 2021 подняли немногим более четверти миллиарда и выделились в самостоятельную глобальную компанию, в которой Миловидов технический директор, гендир Аарон Кац (Aaron Katz), а президент — Юрий Израилевский (Yury Izrailevsky). На фото они на фоне разводного моста, но не питерского, а маленького — амстердамского.

Andy Pavlo Joins ClickHouse to Establish ClickHouse Labs

Уже за одного Энди я бы включил ClickHouse в этот микросписок талантососов. Энди не просто какой‑то там профессор Карнеги‑Меллона, он очень креативный изобретатель и предприниматель — пусть и не слишком коммерчески успешный: его компания (почившая, RIP) ВыдроТюнинг, вышла на этот рынок, похоже, слишком рано (у инвесторов это примерно такой же грех, как выйти слишком поздно). В нашем обзоре Postgresso #6 (67) сохранились весьма экстравагантные фото сооснователей компании.

В статье Энди хвалит ClockHouse — мол, серьёзные исследовательские работы они ведут. Но не только они, и не только об этом он говорит. А в официальном анонсе от имени компании — ClickHouse launches ClickHouse Labs with Andy Pavlo as VP of Database Research — говорится, что Энди продолжает традиции Google, ведь Юрий Израилевский был вице‑президентом разработки в Google, уж он‑то знает потроха гуглового спеннера (но в научной работе, на которую ссылается Энди — Spanner: Google's Globally‑Distributed Database — его имени нет).

Второе приобретение ClickHouse — Дэвид Уилиер (David Wheeler). Он перекочевал сюда, покинув Tembo, где, казалось, прижился, мелькал на всех важных конференциях, представляя их облачные решения — и, хоп! — он уже в ClickHouse. Но в этом не меньшая заслуга Tembo, движущейся по причудливой траектории. Да и траектория Дэвида не менее извилистая. Он, вообще‑то, был археологом, копал черепки на Кипре, в Израиле и в Турецком Курдистане. Об этом расскажем в ч.II — ниже.

А пока о релизе расширения pg_clickhouse читаем в Postgres managed by ClickHouse is now in beta:

Высокопроизводительный Postgres‑сервис на базе локальных NVMe‑дисков с транзакционной производительностью выше на порядок. С помощью встроенного CDC можно за несколько кликов перебросить данные из Postgres в ClickHouse, чтобы в 100 раз ускорить аналитику. Это благодаря унифицированному слою запросов, который устанавливает расширение pg_clickhouse.

Ещё в декабре об этом расширении рассказал Дэвид: Introducing pg_clickhouse: A Postgres extension for querying ClickHouse. Тогда же рассказал и о самом важном — пушдаунах, и о довольно экзотическом для постгресистов SEMI JOIN.

А вот его же «новое в июне» (этого года): What's New in pg_clickhouse v0.3.2: Postgres 19, TLS, Regex, and Memory. Статья «с говорящим названием».

Актуальная сейчас документация по этой теме здесь: ClickHouse Managed Postgres Documentation.

Некоторые релизы

pgNow 1.0.0

Это бесплатное кроссплатформенное средство мониторинга и диагностики в реальном времени (point‑in‑time). Разработчик — Redgate. 1.0.0 — первый официальный стабильный релиз (GA). Умеет подглядеть, что изменилось между двумя заданными моментами времени, выявляя регрессии, всплески активности и «тяжелые» запросы. Умеет находить, где процесс vacuum отстает, помогая предотвратить раздувание таблиц (bloat). И многое другое. Вот анонс на PostgreSQL.org.

dasha

Дмитрий Булашев (@dbulashev Dmitry Bulashev) из Тюмени сделал дашборд с таким вот красивым названием, который анализирует состояние кластеров PostgreSQL, выявляет проблемы и даёт рекомендации по оптимизации. В статье автора на хабре показаны картинки, диаграммки, таблички.

pgBackRest 2.59.1

Добавили поддержку PostgreSQL 19 beta3 и исправили пару ошибок. А вот в вышедшей до этого 2.59.0 было побольше разного:

• Новая опция archive-expire-before для очистки старых WAL‑архивов.

• Пакетное удаление (batch delete) для хранилища Azure.

• Поддержка S3 Outposts и процессной аутентификации S3.

• представлен новый tarball (pgbackrest-{version}.tar.gz) с предгенерированной документацией и кодом, чтобы упростить сборку.

Дела идут, драма, описанная нами в Postgresso #5 (90), действительно закончилась хеппи‑эндом.

Autobase 2.10

Теперь можно управлять кластером (switchover, failover, перезапуск) прямо из Console UI, настраивать системные параметры (DNS, NTP, ядро) в новом разделе System, разворачивать базы на локальном диске без сетевых томов, автоматизировать управление с помощью новых Ansible‑плейбуков для Patroni и отдельных узлов. Детали в release notes. Сайт проекта — вот. А здесь документация.

Postgres Pro AXE 1.1.2

В этой версии исправления и мелкие улучшения. Главное происходило раньше. Если ходить по документации, но — как и в доках Postgres — надо идти в раздел Замечания к выпускам. Там о релизах 1.1.2, 1.1.1, 1.1.0 и 1.0.0.

В предыдущей — в версии 1.1.1 — было:

• hive‑секционирование: добавлена поддержка секционирования при создании аналитических таблиц через процедуру metastore.add_table;

• борьба с раздуванием (bloat): введён параметр axe.use_postgres_snapshot;

• гибкие UNION‑запросы: теперь поддерживаются операции UNION между обычными таблицами‑кучами и представлениями, созданными поверх Parquet‑файлов;

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

• тонкая настройка Parquet: при создании Parquet‑файлов теперь можно явно задавать алгоритм и уровень сжатия, а также размер группы строк (row group size);

• ещё — разное.

LibreDB Studio

Это открытая браузерная SQL‑IDE для PostgreSQL. Разворачивается контейнером, Helm‑чартом или npm‑пакетом рядом с управляемой базой данных (а не на локальных машинах разработчиков).

С помощью ИИ генерит SQL, опираясь на реальную схему подключенной БД. Пробные запросы выполняются строго в BEGIN READ ONLY. Есть пулинг соединений, явные транзакции с авто‑откатом по таймауту и отмена «зависших» запросов через pg_cancel_backend. Вот гитхаб, а вот сайт, там есть документация.

OLTP & OLAP: только смерть разлучит нас

«Знание должно возвращаться в действие. Цикл замыкается лишь тогда, когда синтезированное знание возвращается в операционный контур и меняет то, что произойдет дальше.»

Это из статьи Алексея Евлампиева (Alexey Evlampiev): Operational and Analytical Are Not Separate Architectures. Алексей — архитектор платформ данных из Эйндховена. Там же он отучился в Технологическом университете, но до этого — в МИФИ. Он пишет:

Мой физический бэкграунд проявляется в том, как я мыслю о системах: через призму конечных автоматов, граничных условий и детерминированного поведения в условиях ограничений.

Мыслит он так:

Операционные и аналитические системы — это не разные архитектуры. Это 2 функции — действие и обучение — единой информационной экосистемы.

Это, вообще‑то, не об OLTP/OLAP. Под операционной частью понимается область от приложения до транзакционной базы. А на пересечении двух миров — операционного и аналитического — лежит область принятия решений. Платформы, на которых можно расположить эти миры, превратив их в один — озёра данных. Такие, какими они должны стать (по Евлампиеву), а не такие, какие они сейчас есть.

Здесь лежат 4 статьи в том же духе, почти философские, а вот здесь вполне технические, постгресовые — с листингами, вот такие, например: Test PostgreSQL migrations before COMMIT.

Мы же помним о статьях и даже манифестах Олега Бартунова — серии постов в его ЖЖ, объединённых концепцией NooData (ЖЖ даёт возможность смотреть по тегу):

Возникает необходимость в бесшовной архитектуре данных — NooData, где поток, состояние, контекст, вычисления и хранение сосуществуют в одной временной ткани. Такая архитектура опирается на фундаментальные абстракции: единую временную ось, поток как первичную форму данных, единый вычислительный движок для потоков, OLTP и OLAP с общей семантикой времени.

Итак: МИФИ (кстати, главный поставщик талантов Neon) и Физфак МГУ (Олег — астроном ГАИШ). Акценты разные (обратная связь vs. агентная обработка в реальном времени), технологии реализации разные (Олег предполагает опираться на развивающуюся архитектуру Tengri Data), но и пересечений много.

Субконтинентальные конференции

Индийский субконтинент — устойчивое сочетание. Другие не очень прижились. Индия — страна офшорного программирования, индийские ИТшники от топ‑менеджеров до кодеров‑джуниоров заметны в западных компаниях. Но о самой ИТ‑Индии, мы знаем не так много.

Три постгресовые конференции прошли в Индии, а скоро будет 4-я. Если мы не упустили ещё какую‑то.

• Конференция PGDay Mumbai, которую проводит Mumbai PostgreSQL User Group (PgMumbai), прошла 7 февраля. Вот сайт конференции.

• PGConf India 2026 прошла в Бангалоре, в столице ИТшной Индии 11–13 марта. Это большая конференция с мастер‑классами, и дюжиной аудиторий. 33 доклада, считая мастер‑классы и дискуссии.

• Hyderabad Postgres Days 2026. Прошла 20–21 августа в Хайдерабаде.

• PgPune Event #6 пройдёт 9 октября 2026 года. Пуна — ещё один известный индийский центр ИТ‑жизни, российские ИТшники давно протоптали в этот город тропинку. Организатор — Pune PostgreSQL User Group.

Главные спонсоры во всех сильно пересекаются: мелькают AWS, EDB, Google Cloud, Microsoft. В PGConf платиновый ClickHouse, платиновый местный IITM Pravartak, алмазный EDB. В Posstgresso #1 (86) мы упоминали некоторые доклады, в том числе Михаила Жилина. Добавим ещё интересное:

Платиновый IITM Pravartak — это, оказывается, околоакадемический проект, IITM расшифровывается как Индийский Институт Технологий в Мадрасе. И говорили они, точнее доктор Шанкар Раман (Dr. M. J. Shankar Raman) о местном форке Postgres: ShaktiDB: Extending PostgreSQL for India‑Scale Workloads. Мол, Индия страна многолюдная, и нужно переделать Postgres так, чтобы он выдерживал соответствующие огромные (India‑scale) нагрузки. Но ShaktiDB реализована как расширение. Я бы спросил: а можно разве, не залезая в ядро, соорудить India‑scale‑СУБД?

Был там доклад Experimenting with a Global Index in PostgreSQL: Design, Implementation, and Challenges Дилипа Кумара (Dilip Kumar) от Google. Интересно, что там было.

Хочется немного задержать внимание на конференции в Хайдарабаде, не главной, не маргинальной, не самой большой, не маленькой. О прошлой был восторженный отзыв — PGDay Hyderabad 2024 Reflections Павло Голуба (Pavlo Golub). Об этой отзыв Хари Кирана (Hari Kiran) тоже восторженный:

Всё ещё на волне кайфа (still riding the high) после Hyderabad PGDays 2026, какие же это были невероятные два дня!

В расписании можно увидеть такие доклады:

Keynote: How to Contribute to PostgreSQL, and India's Growing Role in It Па́вана Дэола́си (Pavan Deolasee). Тоже говорил, наверное, об Индия‑скейле.

А вот этот доклад говорит об амбициях индийских разработчиков. Им уже мало проектов/докладов вроде «приспособим Postgres для RAG». Они замахиваются вот на что:

PostgreSQL at the Epicenter of AI: From Vectors to Distributed Training and In‑Database Inference — доклад Сивасанкара (Sivasankar).

Подробней:

Мы представим готовый к промышленной эксплуатации RAG‑пайплайн, в котором PostgreSQL выступает одновременно и в роли векторного хранилища, и в роли слоя оркестрации, предоставляя API для семантического поиска и формирования контекстных ответов.

Далее мы выйдем за рамки использования PostgreSQL как простого хранилища, интегрировав его с распределенными вычислительными фреймворками. Это обеспечит бесшовную оркестрацию задач машинного и глубокого обучения в кластере Ray непосредственно из слоя базы данных. Затем мы раздвинем границы еще дальше, приблизив инференс к данным: запустим обслуживание моделей на базе ONNX прямо внутри PostgreSQL и обеспечим вызов LLM, совместимых с OpenAI, непосредственно через SQL‑запросы с помощью пользовательских расширений.

Индийцы хотят быть современными и в социальном измерении: там был Ужин постгресовых женщин.

Да, и напоминаем о конференции по соседству: PGConf.Nepal 2026 приглашает!

А вот новое для постгресистов место:

pgDay México 2026

Состоится 13 декабря в столице, в Мехико. Основной язык — испанский, но английский как второй язык конференции имеет право на существование. В анонсе даже упомянут ещё и кастильский язык. А, это и есть испанский!

Траектории, ч.II. Tembo и Дэвид Уилер

Эти траектории причудливы, хотя... чьи не причудливы. И эти траектории ещё недавно пересекались, сливались вместе, теперь снова разошлись. Мы подумали, что обе истории интересны как явления в ИТ‑отрасли, и мы их коротко расскажем.

Сначала о Tembo. Основали компанию в 2022 году Даррен Болдуин (Darren Baldwin), Бенджамин Акар (Benjamin Akar) и Рай Уокер (Ry Walker), последний до этого был сооснователем Astronomer (не астрономия, это всего лишь Apache Airflow + ИИ). Начиналось всё с Postgres‑сервиса, компания должна была покорить будущих пользователей Tembo‑облаками, на которых Postgres с самыми разнообразными расширениями. К моменту пивота (это слово уже, оказывается, вошло в русский бизнес‑язык) Tembo Cloud пользовались более 15 000 разработчиков. На пике в команде было около 28 человек. А если уж привлекать разнообразием расширений, то Дэвид Уилер (David Wheeler) — идеальный выбор: он же основатель и мейнтейнер PGXN.

Компания подняла seed‑раунд на $6,5 млн, а затем Series A примерно на $15 млн. Скромные по сравнению с $1 млрд Neon, но зато Tembo и не продавали компанию — они совершили этот самый головокружительный пивот. Повернули траекторию компании градусов на 90.

Повернули в сторону ИИ, куда ж ещё.

Поворот произошёл ещё до появления Claude Code, рассказывают Даррен и Бенджамин в интервью Tembo Deep Dive калифорнийского издания Cerebral Valley. Они знали только Aider.

В 2025 Рай уже писал в блоге Tembo: Tembo — это сверхчеловеческий джуниор‑разработчик (так и написал: Superhuman junior developer). Теперь не до PostgreSQL, не до расширений. В мае 2025 года компания официально объявила о закрытии (sunsetting) своего управляемого сервиса баз данных Postgres. Свернули Trunk — реестр Postgres‑расширений, над которым как раз работал Дэвид. Neon выложил гайд пошаговой миграции из Tembo в своё облако.

В 2026 Tembo уже пасёт целые стада агентов разного происхождения (от разных моделей‑родителей) и разного поведения. Нет, не стада. Агенты — музыканты оркестра, а компания занимается оркестрацией агентов, созданием платформы, на которой этот оркестр сидит. Агента и его муз‑партию выбирают в зависимости от того, какую роль — степень вмешательства выбирает человек‑в-петле (human‑in the‑loop). Сверхчеловеки агенты‑джуниоры и человеки в петле — се ля ви.

«Tembo — это фреймворк фреймворков (harness of harnesses): слой, который раздаёт агентам корпоративный контекст и навыки, защитные ограничители. Это навыки, не привязанные к конкретному кодинг‑агенту, а не привязанные намертво к одному вендору.»

Упоминания PostgreSQL уже днём с огнём. Давид стал лишним или почувствовал себя лишним и перешел в ClickHouse.

Траектория Дэвида началась с археологии. И название его блога, оказывается, от археологии. Он любил теорию, а не систематизацию «черепков размером с ноготь на большом пальце ноги». Потом назвал блог justatheory. Копал на Кипре, в турецкой части Курдистана и в Израиле. Увлёкся, ещё и поработал — мы узнаём из его очень личного и увлекательного блога — барменом‑волантёром в кибуце.

Чтобы не запутаться в миллионе микрочерепков, нужны были базы данных, он ими увлёкся. Основатели Postgres Professional увлеклись Postgres, раскладывая по базам звёзды, а Дэвид — черепки. Потом начал основывать компании, некоторые довольно известные. Его однофамильцу и тёзке, айтишнику и кибербезопаснику пришлось даже объяснять на своём сайте: он всегда использует инициал «A.» чтобы не путали его ни с британским математиком Дэвидом Джоном Уилером (Tiny Encryption Algorithm), ни с разработчиком PostgreSQL и героем нашей повести Дэвидом Э. Уилером, который президент Kineticode и ведущий разработчик Bricolage (а есть ещё физик Джон 'чёрные дыры' Уилер).

И ещё одну компанию (в обоих смыслах) хочется упомянуть. Как он пишет:

У меня новая работа! Вместе с Джошем Беркусом, Дэвидом Феттером, Эндрю Данстаном (Josh Berkus, David Fetter, Andrew Dunstan) и командой других PostgreSQL‑экспертов мы основали PostgreSQL Experts! — все они теперь классики Postgres.

Поскрести графа, ч.II

Обещали и расскажем о графских планах и о PGQ на PGConf.dev 2026. Там была специальная сессия:

Graph database developer meeting.

Были представители проектов Apache/AGE, AgensGraph, pgRouting. На этой сессии:

• Обсудили приоритеты функций SQL/PGQ, которые предстоит реализовать в первую очередь (решили: прежде всего функции, реализующие стандарт, а производительность и прочее — когда получится).

• Обсудили симбиоз Apache/AGE (и других подобных расширений) с SQL/PGQ.

• Обсудили реализацию некоторых приоритетных функций, если позволит время.

Мы выше рассказывали, чего в постгресовом PGQ нет, а в стандарте есть, и даже в Oracle есть.

Сделали немало: теперь есть базовые конструкции паттернов путей, такие как выражения меток (label expression), предложение WHERE в паттерне элемента и паттерне пути, предложение COLUMNs, неявные паттерны рёбер и векторов и так далее. Синтаксис графовых запросов, поддерживаемый в PG 19, включает базовые шаблоны путей (basic path pattern constructs), такие как выражения меток (label expression), предложение WHERE в шаблоне элемента и шаблоне пути, предложение COLUMNs, неявные шаблоны рёбер и векторов и так далее

Но, чтобы они начали нормально работать, нужна поддержка квантифицированных шаблонов элементов, также известных как шаблоны рёбер переменной длины (VLE) [например, ‑[]→{m, n} — о них говорили в той статье, где сравнивали Postgres и Oracle]. Этого требуют многие приложения графовых баз данных. Некоторые детальные спецификации, такие как ограниченные (bounded) и неограниченные (unbounded) пути, а также вопрос о том, реализовывать ли это через рекурсивные CTE или через объединения соединений (unions over joins), ещё предстоит окончательно определить.

Из заметок Хенсона Чои (Henson Choi) известно, что на встрече обсуждались такие возможности, как индекс CSR (сжатое разреженное представление строк, Compressed Sparse Row) и специальные узлы (executor nodes) для поиска кратчайшего пути. Поскольку SQL/PGQ реализован как слой трансляции графовых запросов в SQL, если эти функции улучшат производительность конструкций SQL/PGQ, они также могут повысить производительность соответствующих конструкций в обычном SQL. И у них хорошие шансы быть принятыми, если они смогут применяться и за пределами SQL/PGQ. Для ускорения соединений по внешним ключам, например.

В заключение к теме «поскрести графа» вот дискуссия на ycombinator.

Я бы добавил один, вполне провокационный вопрос: без CTE рекурсии удобней, да. Человеку. Но это человеческий эгоизм, видовой шовинизм — специесизм. А нечеловеку — агенту? Что удобней агенту?

Ещё некоторые ссылки на тему:

PostgreSQL 19: Native Graph Queries Are Here — And You Don’t Need a New Database

Кунал Гупта (Kunal Gupta) рассказывает в том числе и о том, как PGQ поможет строителям микросервисов.

Representing graphs in PostgreSQL with SQL/PGQ

Джон Невин (John Nevin, старший инженер в EDB, работающий над их оркестратором Trusted Postgres Architect), добавил к надоевшем примером с френдами френдов ещё и родителей френдов. Так разница в синтаксисе с PGQ и без него ещё наглядней. Ему нравится статья из до‑PGQ эры: там рекурсивные CTE ещё и параметризованные, а примеры с чем‑то толкиенистским.

pgGraph 1.0: Add Graph Database 'Superpowers' to Postgres — это расширение, оно добавляет графовые функции. Умеет, например, находить кратчайший путь. PostgreSQL с PGQ до этого пока далеко.

Разработчик — компания со странным названием Evokoa Labs. У них есть ещё 2 любопытные Postgres‑разработки:

Polygres SDK, Polygres Agent Skills и терминал polygres‑cli

Это SDK для Python‑приложений с графовым, векторным, текстовым и гибридным Polygres‑поиском. SDK подключается к Runtime API проекта через API‑ключ Polygres. Skills — это агенты для работы с Codex, Claude Code и другими.

pgContext

Это поисковый AI‑движок, встроенный в Postgres. На сайте они пишут аж такое:

Это прямая замена pgvector, сейчас в разработке. Эмбеддинги хранятся и ищутся нативно внутри ваших таблиц, обеспечивая пропускную способность на уровне специализированных векторных баз данных вроде Qdrant.

Вышел AgensGraph 2.17.0.

Это мультимодальная графовая база, построенная поверх PostgreSQL, поддерживает openCypher и частично ISO/GQL (напомним, что PGQ это часть GQL). Поддерживает расширения, PostGIS в том числе. В AgensGraph есть набор из 5 ИИ‑инструментов, среди них MCP‑сервер. В этой версии добились совместимости с PostgreSQL 17 вплоть до 17.10. Разработчик — SKAI Worldwide Open Source Software, бывшая Bitnine.

---

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