Postgresso #3 (88)

Тяжёлое и средней тяжести наследство

Бурное развитие нейросетевых способов разработки подсказывает вопрос:

В мире имеется огромный склад чемоданов без ручек. Это старьё, эта рухлядь, пусть они и милые сердцу и в них вложены труд и талант, их называют легаси. Это и софт (чаще), и железо. Руки программистов-старьёвщиков не доходят до них, до этих легасей, и уже вряд ли дойдут. Но вдруг дотянутся хищные лапищи нейросетей?

Почему бы нет: дело почти рутинное, архитектуры изобретать не надо. Просто переписать с минимумом ошибок. Нет, не просто. Проблемы есть.

• Проблема тренировочных данных для легаси-языков:

  • современные LLM обучены преимущественно на публичных репозиториях (GitHub и др);

  • легаси-код (COBOL, RPG, SAS, PowerBuilder) часто закрыт, проприетарен или представляет собой «игрушечные примеры», не отражающие реальную бизнес-логику;

  • в результате: ИИ «знает синтаксис», но не понимает контекст корпоративных систем. Получается разорванный цикл обратной связи.

• А цикл обратной связи в традиционной разработке таков: Код → Компилятор → Ошибка ^[1] → Исправление → Повтор. А у легаси-платформы (скажем, AS/400, мейнфреймы): Код → ИИ-генерация → Нередко нет доступа к компилятору → Автоматически исправить скорее всего не получится. А без доступа к инструментам валидации ИИ не может «научиться на ошибках» в реальном времени.

• Семантический разрыв между диалектами SQL. Чего уж там, про Oracle -> PostgreSQL у нас же нет иллюзий.

Пусть нам нет дела до проблем с AS/400, но легаси-то и у нас ещё прячется по тёмным углам. И какие легаси – интересные, а то и свои, уникальные.

Но попытки в мире делаются. Относительно успешные.

Вот ANZ Bank (Австралия): использовал инструменты IBM для миграции критических систем с мейнфрейма на облачную платформу (частично с использованием AI-ассистентов).

Mainframe – ANZ’s engine of trust ^[2] – эти австралийские банкиры, точнее Дэвид Свайрз (David Squires), главный мэйнфрейм-инженер в ANZ, говорит:

Среда мейнфреймов не застаивается, она продолжает фокусироваться на модернизации приложений в гибридную облачную среду – на комбинации мейнфреймов и облака в гибкой, безопасной, масштабируемой экосистеме.

Мейнфреймы z16 предлагают адаптировать новейшие технологии и наращивать производительность.

Не перестаю удивляться: эти машины просто невероятны! Ну и как же приятно работать с лучшими специалистами отрасли, бьющимися за то, чтобы мейнфреймное железо оставалось в этом мире самым современным.

В этих словах не только маркетинг: в них (мне) слышна любовь к этим исчезающим большим и умным животным.

AI Coding Agent (IBM) ^[3]

Агента зовут Боб. Его хвалит Артур Сковронски (Artur Skowronski), глава разработки Java & Kotlin: Боб – 1-й инструмент такого рода, для него Java – пассажир 1-го класса.

А вот и Ватсон. Когда-то Ватсон обыгрывал ^[4] каких-то главных викторинщиков, а теперь вот занялся переписыванием легаси:

watsonx Code Assistant for Z ^[5].

Напомню, что System Z ^[6] – это мэйнфреймы, тех, что, в свою очередь, потомки IBM System/390 ^[7]. А переписывать надо в основном COBOL. Чаще на Java для тех же мэйнфреймов.

Да, говорят, что это всё же требует глубокой настройки под специфику и валидации 2-ногими экспертами.

Интересно ещё вот что: как пишут в Accelerated, Gen AI powered Mainframe App Modernization with IBM watsonx Code Assistant for Z ^[8], этот ассистент построен на собственном их IBM Granite, опенсорсной модели, обученной на 116 языков программирования.

А вот здесь даже не IBM-мэйнфреймы, а юнисисовские – для ещё более нешуточного клиента: Software Modernization Assured. Unysis Mainframe to AWS GovCloud – COBOL to Java, U.S. Air Force SBSS ILS-S Modernization (TSRI) ^[9]. – это, конечно, их опечатка: Unisys, а не Unysis, ср. с Мэйнфреймы фирмы UNISYS: от Burroughs до наших дней ^[10] на сайте Открытых Систем ^[11].

Кстати, желающие применить ИИ к Air Force уже выстроились в очередь: вот компания Illumination Works ^[12], вместо того, чтобы заниматься иллюминацией, не только подготовила Agentic AI Natural Language Reasoning ^[13] для них, но и позиционирует себя как поставщик замечательной аббревиатуры с 3 “а” подряд: DAaaS (Data Analytics). У них агенты на базе Mistral. Умеют работать с MS Word, MS Excel и PDF, с промышленным IoT (IIoT), умеют автоматически упорядочивать права доступа и многое другое.

Небезызвестный Wells Fargo modernizes thousands of applications faster with software intelligence ^[14] – более 4500 приложений. Анализ с применением ИИ. А ING Bank модернизировал более 1,5 миллиона строк кода COBOL, включая CICS, DB2 и JCL – см. COBOL-to-Java Migration Case Study ^[15], – используя SoftwareMining ^[16] для автоматизированного перевода на Java.

И тут на сцену выходит Google: Accelerate mainframe modernization with Google Cloud AI ^[17]. Они пишут в блоге Google Cloud ^[18], что используют Gemini 3 ^[19].

А что в России? Мало кобола, много тумана. Вот хабр, но всё же не российский опыт ^[20]. Но с мэйнфремами и с ИИ. В блоге АльфаСтрахования ^[21]: Как я мигрировал COBOL-код мейнфрейма на Java: разные подходы и почему ANTLR ^[22].

А вот сверхлаконично и гипертуманно, зато уже о наших рукастых носильщиках чемоданов без ручки: Поддержка Legacy-системы и как навести порядок в устаревших технологиях ^[23] – упоминается и ритейл, и “жёлтый банк”.

Но хватит об этом. Ниже ещё напишем о миграции – с ещё не покрывшихся мхом систем на Postgres. А пока:

Релизы

credcheck 4.7 ^[24]

Канадская компания HexaCluster.ai ^[25] не без странностей: например, о новых релизах она оповещает из Антананариво (это столица Мадагаскара). О ней мы писали в Postgresso 2 (63) ^[26]. Тогда мы дивились, что один из самых продуктивных разработчиков во французской компании Dalibo ^[27], Жиль Дароль (Gilles Darold, самый известный его проект – Ora2Pg ^[28]) стал техническим директором компании HexaCluster ^[29], тогда мало кому известной. Говорят, в 90-е он работал в Астрономической Лаборатории Calern ^[30] в Ницце – почти бусидо ^[31] основателей Postgres Professional.

Как бы то ни было, на сайте этой компании есть примечательный подзаголовок: Legacy to Modernized Applications & PostgreSQL Consulting. И нарисована схемка-отношение: были системы на Oracle, SQL Server, DB2 и Informix, стали – на PostgreSQL. По их словам – вплоть до 100% автоматизации. А между Oracle, SQL Server, MySQL, MariaDB и PostgreSQL у них кросс-платформенная миграция и репликация в реальном времени.

credcheck – опенсорсный проект (лицензия PostgreSQL) HexaCluster ^[32]. Это утилита-расширение для настройки политик безопасности паролей (сложность, история, срок действия, блокировка при подборе). Там много настраиваемых параметров, таких как срок протухания пароля, его замысловатость и так далее. В этом минорном релизе ничего примечательного нет, более значительные в мажорном credcheck 4.0 ^[33]. Загрузить можно отсюда ^[34].

Ещё мадагаскарские новости: pg_dbms_job v2.0 ^[35]

Это даролеский аналог ораклового пакета DBMS_JOB. Планировщик в смысле шедулер. Вот документация ^[36], загружать можно отсюда ^[37]. О таких утилитах можно, наверное, сказать: “скромненько, но со вкусом”.

Autobase 2.7.0 ^[38]

Autobase задуман как опенсорсная замена облачной Amazon RDS. Половина названия – Auto – не предполагает автоматической настройки параметров, индексов и запросов как, скажем, у Postgres.ai ^[39], но особенность и не в этом.

Это вовсе не аналог облачных DBaaS, а их в некотором смысле противоположность: основатель компании говорит автору не слишком прозрачного блога ^[40]:

Эра «Облако прежде всего» (Cloud First) переходит в эру «Контроль прежде всего»” (Control First). По мере роста затрат и повышения важности суверенитета данных инструменты вроде Autobase предоставляют ту золотую середину, которую так ждали.

И всячески подчёркивает много где, что преимущество в полном контроле за своей базой. И что Autobase может работать на “голых” (bare metal) серверах, без виртуализации.

Ну а имя Auto оправдано тем, что многие важные операции с кластерами автоматизированы (в основном скриптами Ansible): развертывание, failover, бэкапы, восстановление, апгрейды и масштабирование – создаётся сразу HA-кластер, готовый для продакшн.

Autobase Tech ^[41] приписана к Испании, основатель Виталий Кухарик (Vitaliy Kukharik ^[42], из СПб) aka vitabaks. Сама Autobase сначала называлась postgresql_cluster, её тогда ещё хвалил ^[43] Алексей Лесовский, ныне руководитель отдела разработки Postgres Professional.

В этом релизе изрядные изменения: как и обещали, заинтегрировали DBDesk Studio ^[44] индийской компании Zexa Technologies ^[45]. Это логично ^[46]: у них контроль тоже любимая тема. В доке к минималистской DBDesk ^[47] создатели хвалятся прежде всего его безопасностью: Local-First Security – данные не покидают локальный компьютер. И информация о соединении хранится исключительно локально.

DBLab 4.1 ^[48]

DBLab (она начинала как Database Lab) – детище возглавляемой Николаем Самохваловым (Nikolay Samokhvalov) Postgres.ai. В этом релизе в том числе: временные лицензии на защиту (protection leases), поддержка Prometheus и Teleport ^[49].

Клон нельзя было удалить ни вручную, ни автоматически, пока защита не снималась явно. Это создавало риск: забытые защищённые клоны могли бесконечно занимать место на диске. Теперь после истечения заданного срока клон автоматически становится незащищённым. “Клоны убирают за собой” – как написано в блоге. Что такое клон в данном контексте – объяснять не будем: это центральное понятие Postgres.ai.

4.1 научился работать на ARM64 и Colima ^[50]: теперь клоны будут размножаться и на маках.

Ещё любопытная возможность: в RDS/Aurora обновление данных (data refresh) не задевает продакшн. Речь вот о чём: запуск pg_dump напрямую на продакшен-инстансе RDS сопряжён с рисками: в процессе дампа удерживается горизонт xmin, что блокирует работу vacuum и приводит к накоплению «мертвечины» (к bloat). Вплоть до того, что на сильно нагруженных системах это создаёт риск краха счётчиков (transaction ID wraparound).

А в DBLab 4.1 появилась утилита rds-refresh – она:

1. находит последний автоматический снапшот RDS,

2. разворачивает из него временный RDS-инстанс,

3. направляет через DBLab обновления на этот временный инстанс,

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

В Q&A ^[51] можно прочитать признания:

Мы ещё не полностью автономны. PostgresAI отслеживает состояние, ставит диагнозы и готовит pull request’ы. Но проверяете, утверждаете и сливаете изменения вы сами. Человек участвует в каждом изменении [human-in-the-loop – опять эти “люди в петле”].

Мы создаём Self-Driving Postgres. База данных сама следит за собой, диагностирует проблемы и предлагает исправления – улучшения производительности, патчи безопасности, обновления без простоя. Каждая рекомендация тестируется и проверяется на клоне ваших реальных данных.

А в роудмэпе можно прочитать:

2026 AUTOPILOT
Безопасные операции выполняются автоматически.
Рискованные изменения по-прежнему требуют одобрения.
Self-driving: первые версии — в конце 2026 года.

2027+ SELF-DRIVING
Полная автономность.
Postgres работает сам.
А вы занимаетесь развитием продукта.

Немного контекста. Есть и университетские проекты самонастраиваемых СУБД. На этот раз дадим ссылку на Пекинский Университет, где в лаборатории PKU-DAIR (Data and Intelligence Research) предлагают:

• DBTune: A customized and efficient database tuning system ^[52] и

• HyperTune: Efficient Hyper-parameter Tuning at Scale ^[53].

А, например, майкрософтовский Intelligent tuning ^[54]умеет настраивать в том числе автовакуум.

Что касается клонов, то они прибывают из разных направлений: из Азербайджана, из его столицы – Баку:

pgclone v4.0.0 ^[55]

Это опенсорсное расширение PostgreSQL, которое клонирует базы данных, схемы и объекты напрямую через SQL, используя кастомные воркеры.

В 4.0.0 важное изменение: когда вы говорите CREATE EXTENSION pgclone, схема pgclone создаётся автоматически, и все функции попадают в эту схему, а префикс pgclone_ удаляется. Настолько серьёзное, что надо грохнуть старое расширение и создать новое. Работает с PostgreSQL 14-18.

Конечно, это клоны совсем не того продвинутого типа, что у Postgres.ai. Но даже сам нейминг показателен.

В pgclone полная поддержка DDL (индексы, ограничения PK, UNIQUE, CHECK, FK, EXCLUDE, триггеры, представления и последовательности – без зависимостей от pg_dump, pg_restore или внешних shell-скриптов. Встроенное маскирование с автоматическим анализом и подсказками: какие колонки надо бы маскировать (анонимизировать).

Вот гитхаб ^[56], 4.0.0 Release Notes ^[55], PGXN ^[57], гайд ^[58], об асинхронных операциях ^[59], архитектура ^[60], тестирование ^[61].

Ведёт этот проект Валех Агаев (Valeh Agayev aka valehdba). В Азербайджане есть своя PUG ^[62]. Но конференций, кажется, пока не устраивает.

А ещё есть такие вот:

NeurDB ^[63]

Коллектив по-восточному загадочный. Контрибьюторы в основном сингапурцы с китайскими фамилиями. Пишут, что это не просто база данных с AI-функциями – это AI-native система данных, которая учится, адаптируется и оптимизирует себя в реальном времени.

• AI-Native архитектура: AI и обработка данных глубоко интегрированы в движок БД, отсюда бесшовное обучение ^[64], инференс и управление моделями.

• Intelligent Analytics: Встроенные AI-операторы позволяют запускать предиктивную и генеративную аналитику прямо в SQL, без внешних пайплайнов.

• Autonomous Operation: Самонастраивающиеся, самомасштабирующиеся и самовосстанавливающиеся механизмы непрерывно оптимизируют производительность и использование ресурсов.

• Unified AI & Data Platform: Единая система для управления данными и полного AI-цикла, обеспечивает безопасность, низкую задержку и упрощённые workflows.

В версии 0.5.0 ^[65], номер которой вряд ли говорит о зрелости проекта, сказано о том, что улучшен метод доступа NRAM (NeurDB Access Method). К сожалению, этот релиз состоялся в конце 2025 года, так что пожелаем проекту здоровья, не повторить судьбу Эндипавловских Выдр ^[66].

pgEdge Launches AI DBA Workbench, an AI Co-Pilot for Database Administrators ^[67]

Эта ссылка на сайт PostgreSQL.org, а вот и анонс на сайте компании: Your Postgres estate monitored, diagnosed, and under control. Introducing the pgEdge AI DBA Workbench ^[68].

pgEdge – Postgres-компания, позиционирующая себя как ведущий поставщик опенсорса уровня энтерпрайза. AI DBA Workbench for Postgres, соответственно, опенсорсная утилита для мониторинга и управления PostgreSQL. С ИИ-автоматизацией, но без претензий на автономность – она помощник админу, а не замена.

Умеет многое:

• Собирать данные о производительности PostgreSQL.

• Мониторить производительность запросов.

• Отслеживать активность VACUUM.

• Контролировать состояние подключений.

• Измерять пропускную способность WAL.

• Отслеживать задержку репликации.

• Обнаруживать аномалии с помощью трёхуровневой системы.

• Использовать статистические базовые показатели для анализа.

• Сопоставлять с шаблонами через векторное сходство.

• Классифицировать проблемы с помощью ИИ.

• Выявлять проблемы до их перерастания в сбои.

• Работать как классический инструмент наблюдаемости без ИИ и включать ИИ при необходимости.

Утилита не привязана к определённой LLM. Настраивается на разные, задаётся параметр. Будет работать хоть на Amazon RDS или Supabase, хоть дома.

Техдир pgEdge – Дейв Пейдж (Dave Page, в Core Team PostgreSQL, создатель pgAdmin, ранее вице-президент и главный архитектор EDB). Не могу забыть:

«В ноябре прошлого года, после почти двух десятилетий работы на моём предыдущем месте, я понял, что не хочу работать в компании, которая быстро становится ориентированной на искусственный интеллект ^[69]. Я перешёл в pgEdge, где внимание ^[70] и усилия сосредоточены на распределённом PostgreSQL.» см. Postgresso 7-8 за 2025 (80-81) ^[71].

Но, чего уж, pgEdge действительно пока фанатически привержена open source, в отличие от EDB со смешанной бизнес-моделью.

pg_textsearch 1.0 ^[72]

Создатели этого опенсорсного (лицензия Postgres) расширения – Tiger Data, некогда Timescale ^[73]. Их pg_textsearch поддерживает поиск Okapi BM25 ^[74]. Оно сочинено на C и работает напрямую со слоем хранения Postgres, добавляет свой оператор <@>, который можно использовать в SQL.

У ранжирования ts_rank в tsvector/tsquery есть недостатки, о которых они говорят в pg_textsearch 1.0: How We Built a BM25 Search Engine on Postgres Pages ^[72]. BM25 помогает от них избавиться. Авторы поясняют схемами архитектуру своего решения.

Создатели сравнивают на тестах своё детище с ParadeDB ^[75] v0.21.6, которая использует библиотеку Tantivy ^[76], которая, в свою очередь, вдохновлена Apache Lucene ^[77]. Номер версии намекает на готовность к реальному, а не экспериментальному использованию. Вот гитхаб ^[78] проекта.

Energent.ai ^[79]

Универсальная no-code платформа для анализа данных через ИИ, поддерживает PostgreSQL как один из источников, не специализируется на администрировании. Их штаб-квартира в Абу-Даби в ОАЭ, но и с офисом в Пало-Альто, США. Основатели – Рейчел Ху (Rachel Hu, CEO) и Кими Конг (Kimi Kong, CTO), команда с опытом в Google DeepMind, AWS, Stanford.

PostgreSQL: storage_engine 1.0.7 – columnar + row-compressed Table Access Methods for PostgreSQL 16-18 ^[80], а также storage_engine: Two High-Performance Table Access Methods for PostgreSQL Analytics and HTAP Workloads ^[81]

Сауло Жозе Бенвенутти (Saulo José Benvenutti, saulojb) из Порто Униаун (Porto União, это в Бразилии) наваял расширение, нескромно названное storage_engine ^[82]. Оно даёт сразу 2 высокопроизводительных метода доступа к таблицам для аналитических и HTAP-нагрузок:

colcompress: колоночное сжатое хранилище с векторизованным выполнением, с обрезкой (pruning) min/max на уровне чанков, параллельным сканированием и сортировкой типа MergeTree.

rowcompress: строковое хранилище с параллельным сканированием, поддержкой DELETE/UPDATE через битовые маски удалённых записей и кэшем декомпрессии LRU.

Оба метода доступа к таблицам (AM) сосуществуют параллельно со стандартными heap-таблицами в одной базе данных. Все объекты каталога изолированы в схеме engine, что делает расширение безопасным для установки рядом с citus_columnar или любым другим колоночным расширением (все экспортируемые символы C имеют префикс se_, чтобы избежать конфликтов линковки).

Возникли не на ровном бразильском месте: storage_engine – форк Hydra Columnar ^[83] (которая сама произошла от citus_columnar ^[84]). При этом автор добавил: расширенный rowcompress, полную поддержку DELETE/UPDATE, обрезку min/max на уровне чанков и переработал параллельное сканирование. Опция orderby в стиле MergeTree и обрезка по зонам-картам напрямую вдохновлены ClickHouse ^[85] – отдаёт должное Сауло Жозе.

Всё со значительной – подчёркивает автор – экономией места хранения и без существенного ущерба для производительности запросов по сравнению со стандартными heap-таблицами.

Совместима с PostgreSQL 16 и новей. Гитхаб ^[86], PGXN ^[87]. В статье storage_engine: Two High-Performance Table Access Methods for PostgreSQL Analytics and HTAP Workloads ^[81] Сауло довольно подробно объясняет, что он сделал и, в том числе, с чего бы два – казалось бы – совсем разных метода объединять в одном расширении.

Немного о наших (во всех смыслах) достижениях.

Postgres Pro AXE 1.1.0 ^[88]

Скоростной софт для аналитики. С вертикальным хранением. В этой версии есть ключевые изменения: 

1. Поддержано Hive-секционирование при создании аналитических таблиц с помощью процедуры metastore.add_table.

2. Обеспечено предотвращение удержания горизонта при аналитических запросах.

3. Сделаны доработки по обратной связи:

   • добавлена поддержка UNION операций,

   • улучшено взаимодействие с S3.

Эта версия только что вышла. Поддерживаемые ОС: ALT Linux 11, Astra Linux Smolensk 1.8. Но скоро добавятся: Debian 13, RedOS 8, Ubuntu 24.04, RHEL 10. Вот документация ^[89] проекта.

ProGate 1.2.0 ^[90]

Это важный для экосистемы элемент. Он полезен не только для традиционного занятия: миграции с Oracle на Postgres ^[91], его возможности много шире. О нём не надо забывать ^[92], когда вообще речь заходит о преобразовании самых разных данных (например, из Shardman ^[93]; ну а Oracle может не только отдавать, но и принимать данные – см. список изменений). Но это особый разговор. В этой версии много изменений:

• Обеспечена безопасность функционирования всех компонентов.

• Добавлен интерфейс администратора Postgres ProGate.

• Добавлена возможность управления проектами, которые включают трансферы данных и соединения.

• Добавлена поддержка механизмов политики безопасности содержимого ^[94] (Content Security Policy).

• Добавлена поддержка PostgreSQL 9 утилитой procopy ^[95].

• Добавлена базовая поддержка чтения изменений из Shardman ^[93].

• Добавлена поддержка Oracle в качестве приёмника данных для репликации изменений.

• Устранена зависимость проверки корректности переноса данных procheck ^[96] от клиента Oracle.

• Реализованы возможности аудита действий, выполняемых пользователем в приложениях командной строки. Приложения осуществляют сбор событий, связанных с изменением состояния выполнения задач миграции и репликации данных.

Самые свежие версии Shardman сегодня такие: Postgres Pro Shardman 18.3.3 ^[97], а также 17.9.2 ^[98] и 14.22.2 ^[99]. Там в основном исправление ошибок и ликвидация уязвимостей.

Postgres Pro Backup Enterprise 3.3.0 ^[100]

Да, он Pro и Enterprise, поддерживает Postgres Pro Enterprise, но и PostgresPro Standard, но и ванильный PostgreSQL тоже (поддерживаются версии Postgres: 15 и новее).

В этой версии немало новых параметров и возможностей. В замечаниях к релизу ^[100] и в документации ^[101] все подробности.

Postgres Pro Enterprise Manager 2.5.1 ^[102]

Исправлена ошибка миграции с версии PPEM 2.4 или 2.4.1 на версию 2.5, которая могла приводить к ошибке фоновой обработки узлов репликации. При обновлении на версию 2.5.1 дополнительных действий не требуется. Если у вас не развёрнуты кластеры репликации, обновление с версии 2.5 не требуется. Подробности здесь ^[103].

Наследство (продолжение – без мха и патины)

Продолжим тему, с которой начали, в менее экзотичном контексте: Teamfront Achieves a 10x Faster Database Migration to Amazon Aurora PostgreSQL with Caylent Accelerate ^[104]

Мигрировали с SQL Server. И не просто в Аврору. Тут не обошлось без Babelfish ^[105] (в переводе Вавилонская Рыбка ^[106]-толмач, подразумевается её способность переводить). Амазон её создал и сразу – было это осенью 2021 – открыл код. Рыбка конвертирует запросы SQL Server в запросы к Aurora PostgreSQL: Goodbye Microsoft SQL Server, Hello Babelfish ^[107]. Это, однако, привело к большому возбуждению ^[108] в Postgres-сообществе. Мы об этом писали в Postgresso 36 ^[109]:

Альваро [Эрнандес (Álvaro Hernández Tortosa)] привлекает Дилемму инноватора ^[110] и задаёт ещё один интересный вопрос: хотим ли мы (то есть сообщество), чтобы Babelfish стала “MariaDB у PostgreSQL”?

Как бы то ни было, компания Teamfront навострила своего ИИ-агента Caylent ^[111] на миграцию. И докладывает о результатах.

• Перенесли 2500+ хранимых процедур.

• Сократили сроки миграции с планируемого ~1 года до 4 месяцев.

• Caylent Accelerate автоматически выявил 1 850 мёртвых душ: неиспользуемых процедур. Их поганой метлой исключили из миграции.

• Caylent Accelerate сам обработал 430 процедур за 3 часа.

• 2-ногие эксперты доработали 214 сложных процедур (с динамическим SQL, специфичными функциями SQL Server и пр.).

Итого:

• 70% процедур – авто-конверсия через ИИ.

• 20% – ИИ + human-in-the-loop (разработчик корректирует)

• 10% – ручная доработка.

Образование

Книги

PostgreSQL 16 Оптимизация запросов – Павел Толмачёв ^[112]

Книга «Postgres 16. Оптимизация запросов» знакомит читателя с работой планировщика: в ней рассказывается о методах доступа к данным и способах соединения, учим читать планы выполнения запросов, говорим о важности статистики и рассматриваем основные приемы оптимизации.

Основой послужил учебный курс «QPT. Оптимизация запросов ^[113]», материалы которого Павел Толмачёв переработал в формат небольшой книги, чтобы нужная информация всегда была под рукой. Эту книгу удобно читать в метро или даже на остановке, когда нет возможности открыть ноутбук и обстоятельно погрузиться в изучение и эксперименты. Можно скачать в формате PDF ^[114].

AI-Ready PostgreSQL 18 Is Out: Why AI Applications Win or Lose at the Seams – Vibhor Kumar & Marc Linster ^[115]

Соавтор книги – Вибхор Кумар пишет, что книга уже вышла. Предисловие Эда Бояджяна (Ed Boyajian, член совета директоров и бывший гендир EDB). Так и есть: вот, на Амазоне ^[116]. Это вообще EDB-шная туса: Марк Линстер побывал техдиром EDB, а Вибхор сейчас там в качестве Customer Experience Technical Fellow (даже не хочется переводить такую красоту). Но это ладно, он соавтор книги PostgreSQL 16 Administration Cookbook ^[117] вместе с в том числе покойным главой 2-nd Quadrant Саймоном Риггсом (Simon Riggs).

Курсы

Опубликован новый курс DBS. Основы безопасности PostgreSQL 16 ^[118]. Курс рассказывает про конфигурирование подключений клиентов к СУБД и про управление доступом внутри самой СУБД. Предназначен в первую очередь для администраторов, поскольку рассматривает вопросы настройки экземпляра, но может быть интересен и разработчикам, позволяя взглянуть с другой стороны – в контексте безопасности – на использование ролей и распределение данных по схемам и таблицам. За основу взят модуль “Управление доступом” курса DBA1-13, который в DBA1-16 заменён обзорной темой. Исходный материал был существенно переработан, дополнен новыми темами и новинками версий 14-16. Курс разработали Алексей Береснев, Илья Баштанов, Егор Рогов и Павел Лузанов. Авторы готовы принимать тест для преподавателей.

ИТ и ВУЗы

ИТ-компании обязали поддерживать вузы, но это не так просто, как может показаться. Взгляд из МФТИ, ч.1 ^[119] и ч. 2 ^[120]

Вообще-то, крупные компании это делают вполне добровольно. В том же МФТИ профессор Александр Тормасов преподаёт и преподавал, будучи тогда, ещё в конце прошлого века, начальником отдела перспективных разработок SWsoft (которая потом стала Parallels) – а что, дело доброе, всем на пользу, но и отличный способ фильтровать и хантить талантливых студентов. Ну а в этой 2-частной тедвайзеровской статье действительно говорят о серьёзных проблемах.

Статьи

Нет, не статьи. Одна статья – чтобы не перегружать мозг ^[121] на майские праздники (зато в этом выпуске было много релизов).

How moving one word can speed up a query 10–50x ^[122]

Авторы – Николай Самохвалов, это его блог, и Максим Богук (Maxim Boguk), он работает ^[123] в Цапле Данных – Data Egret ^[124], возглавляемой Ильёй Космодемьянским (Ilya Kosmodemiansky, с Самохваловым они вели незабываемые ruPostgres.Вторники ^[125]).

Максим обратил внимание на то, что два логически эквивалентных запроса с AND EXISTS vs. AND NOT EXISTS и AND NOT deleted vs. AND deleted приводят к огромной разнице в производительности.

Дальше обсуждение весьма тонких эффектов и, конечно, тесты.

Конференции

PGConf.dev ^[126] 2026 ^[127]

Уже скоро: 19-22 мая в Ванкувере. Вот расписание ^[128]. Программный комитет конференции:

• Мелани Плейгман (Melanie Plageman, Microsoft),

• Дилип Кумар (Dilip Kumar, Google),

• Джонатан Кац (Jonathan Katz, Databricks),

• Пол Рэмзи (Paul Ramsey, Snowflake),

• Джейкоб Чемпион (Jacob Champion, EDB).

Но есть ещё и особый Вторничный Комитет (Tuesday Planning Committee). Зачем? Видимо, из-за перегрузок. Заявки на Community Discussions (CDS) подаются до 14 апреля. Времени мало. Вторничный Комитет именно ими и занимается, а общее расписание планируется заранее основным Программным Комитетом – в среду и в четверг будут “обычные” доклады в 3 потока. В пятницу – unconference. Итак, Вторничный:

• Клэр Джордано (Claire Giordano, Microsoft),

• Кори Ханкер (Corey Hunker, Apple),

• Матиас ван де Меент (Matthias van de Meent, Databricks),

• Пол Джангвирт (Paul Jungwirth, Illuminated Computing),

• Роберт Хаас (Robert Haas, EDB).

А за сессию постеров отвечает Андрей Бородин (Andrey Borodin, Yandex Cloud).

Можно заметить, что корпоративный состав заметно изменился: 2 от Databricks (столько же от классиков жанра – EDB), Snowflake, Apple.

А вот эта ещё не скоро:

PGConf.EU 2026 ^[129]

Пройдёт в Валенсии 20-23 октября. 16-я по счёту, предыдущая была в Риге. Community Events Day будет в пятницу 23-го. Расписания пока нет.

PGDay Armenia 2026 ^[130]

Только что прошёл в Ереване – 30 апреля. Ждём впечатлений. Прилетел ли Брюс Момджан или докладывал через эфир? Тема доклада, кстати, интересная: Postgres as an MCP ^[131] Server.

Ещё, например, в программе: Choose Your Own Adventure: Postgres 18 Demos Роберта Трита (Robert Treat, гл. инженер баз данных в Amazon Web Services); разработчица Postgres Professional Влада Погожельская доложила о When the PostgreSQL Planner Gets Too Optimistic: Index Choice and Join Estimates.

Организатор конференции – Эмма Сароян (Emma Saroyan).

DUMP-EKB ^[132]

Большая конференция прошла 26 апреля в Екатеринбурге (устроители пишут: главная ИТ-конференция на Урале) и произвела на присутствовавших постгресистов большое впечатление ^[133]. Особенно масштабом: более десятка параллельных секций. Вот программа ^[134].

Секция Backend – двойная, с 14 докладами. Вторая начиналась с воркшопов, но дальше тоже доклады. Вот некоторые, чтобы у вас было представление об этой находящейся на периферии постгресового сознания конференции:

• Админы скрывали это от нас годами: Rust + PostgreSQL в реальном проде ^[135] – Роман Китаев, разработчик в Точка Банке,

• Chaos Engineering для тех, кто в гробу его видал ^[136] – Лев Алимов, стафф-инженер в Т-Банка (напоминаем, что в прошлом выпуске ^[137] мы рассказывали немного о китайских инженерах хаоса, даже о Chaos as a Service ^[138]),

• Как backend-разработчику понять ML ^[139] – Степан Ляхов, старший инженер по Golang в Ad Platform Team, MAGNIT TECH,

• Как мы разрабатывали плагин sql для платформы Giga IDE ^[140] – Владимир Ярославский, главный эксперт по технологиям в Сбере,

• Распределённые системы: проблема часов, датацентры, сеть ^[141] – Илья Солтанов, техлид в Точка Банке. В описанию в анонсе ну прямо таки философская заумь: «Распределённые системы: проблема часов, датацентры, сеть»Разберём причинность образования множества осей времени и какое влияние оказывают на них високосные секунды, затронем синхронизацию систем, а также какие трудности возникают при работе со временем.

• Что я узнал из разработки агентов ^[142] – Алексей Лобанов, техлид в SberDevices.

---

Пока всё, хороших праздников.