Postgresso #11-12 (84-85)

Postgres Pro Enterprise 18.1.1 ^[1]

До Нового Года успела выйти 18-я версия Postgres Pro Enterprise. Полный список нового слишком велик для нашего жанра. Вот избранное.

• Добавлена возможность создавать таблицы, которые разделяются на секции при помощи внешнего ключа. Внешний ключ используется как ссылка на родительскую секционированную таблицу и определяется в предложении PARTITION BY REFERENCE ^[2].

• Обновлены модули, в том числе BiHA ^[3]. В ней много важных изменений:

  • Расширение biha ^[4] обновлено до версии 1.7.

  • Появилась экспериментальная функциональность, позволяющая объединять узлы BiHA-кластера в сегменты (логические узлы), которые можно разместить в географически распределённых центрах обработки данных. Подробности в разделе Геораспределённость и катастрофоустойчивость ^[5].

  • Добавлен специальный защитный механизм watchdog ^[6], который помогает предотвратить зависание узлов и проблему разделения кластера (split-brain). Механизмом watchdog можно управлять с помощью параметра конфигурации biha.watchdog_timeout ^[7].

• В расширение proxima ^[8] добавлен экспериментальный модуль KVik ^[9]. Модуль KVik предназначен для систем с высокой нагрузкой на чтение данных. Он кеширует в оперативной памяти ^[10] данные баз данных Postgres Pro и обеспечивает быструю работу с ними через протокол RESP (Redis Serialization Protocol). Основные возможности KVik:

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

  • поддержка команд RESP, таких как SET, GET, DEL;

  • автоматическое аннулирование данных в кеше при их изменении в базах данных Postgres Pro операторами INSERT, UPDATE, DELETE;

  • автоматическое изменение данных в базах данных Postgres Pro при их изменении в кеше операциями SET и DEL.

• Модуль AQO ^[11] (Adaptive Query Optimizer) 4.0 использует машинное обучение ^[12] для автоматического исправления ошибок в планах выполнения запросов, возникающих в стандартном планировщике. Гитхаб AQO ^[13].

• Изменено поведение ^[14] AQE ^[15] (адаптивное выполнение запросов). Теперь для работы AQE необходимо для параметра конфигурации compute_plan_id ^[16] установить значение auto (по умолчанию) или on, в противном случае AQE отключено.

• В расширении pgpro_multiplan ^[17] похожие изменения. Теперь, чтобы включить вычисление идентификаторов планов в ядре, которое используется в pgpro_stats ^[18], для параметра конфигурации compute_plan_id ^[16] необходимо установить значение on. В противном случае все значения поля равны 0.

• Усовершенствован поиск k-NN ^[19].

• Более либеральная политика паролей: добавлены новые параметры OLD_PASSWORD_TIME и OLD_PASSWORD_MAX для команд CREATE PROFILE ^[20] и ALTER PROFILE ^[21]. Теперь какое-то (заданное) время можно пользоваться и новым и старым паролями (подробности, в т. ч. о других параметрах – в документации Postgres Pro Standard 18.0.1 ^[22].

• Обновлены: apache_age ^[23] до 1.6.1, orafce до 4.16.3, pg_filedump ^[24] до 18.1, pg_hint_plan ^[25] до 1.8.0.1, pg_probackup ^[26] до 2.8.12 Enterprise, pgpro_controldata ^[27] до 18.2.0, pgpro-orautl до 2.2, pgvector до 0.8.1, tds_fdw ^[28] до 2.0.5 и другие модули и утилиты.

• Асинхронный ввод-вывод (AIO).

• Оптимизация SkipScan.

• Расширенные инструменты мониторинга.

• Эффективный Vacuum.

На CNews вышла статья, где новшества вполне складно изложены и акценты адекватно расставлены:

Обзор: Рынок СУБД 2025 – Postgres Pro Enterprise 18: встроенный in-memory кеш и новые горизонты отказоустойчивости ^[29]

Новые контрибьюторы

Появилось 12 новых контрибьюторов – не major contributors, но и не просто contributors: с совсем недавних пор, после обсуждения ^[30] в рассылке hackers, их величают Significant Contributors. Вот эта дюжина:

• Антонен Бонфуа (Anthonin Bonnefoy),

• Кэри Хуанг (Cary Huang),

• Дирк Кравчик (Dirk Krautschick),

• Эрик Винхольд (Erik Wienhold),

• Джапин Ли (Japin Li),

• Джонатан Гонсалес (Jonathan Gonzalez),

• Цзюньван Чжао (Junwang Zhao),

• Леонардо Чекки (Leonardo Cecchi),

• Полина Бунгина (Polina Bungina),

• Сами Имсейх (Sami Imseih),

• Швета Малик (Shveta Malik),

• Тендер Ванг (Tender Wang).

Двое из списка мне недавно попадались в PostgreSQL Person of the Week ^[31] Андреаса Шербаума (Andreas Scherbaum ^[32]).

Dirk Krautschick ^[33] – старший архитектор решений (senior solution architect) в Aiven, живёт в Германии. Но он не совсем немец, он бейсиканец: real native language is in fact not German but BASIC. Он до сих пор в сообществе Oracle, хотя чаще работает с Postgres.

Полина Бунгина (Polina Bungina ^[34])

Инженер баз данных PostgreSQL в Zalando, живёт в Берлине. Из Санкт-Петербурга. Начинала работу с базами с Greenplum 5. Сейчас в основном работает над Patroni, а также контибьютит в Spilo (Postgres-оператор от Zalando) и некоторые расширения.

Кроме того Полина ещё большая шутница (шутникесса?), чем Дирк. Она, например, признаётся, что её хобби:

• макияж,

• преступления (true crimes) и

• авиакатастрофы.

Некоторые из них я практикую, а о других только читаю или слушаю подкасты…

На всякий я спросил у Перплексити: она шутит?

“Да, – сказал он (или она? или оно?) – она говорит это в ироничном ключе, создавая абсурдный контраст между безобидным хобби и мрачными темами.” – и от сердца отлегло.

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

(Почти) Postgres-философия

Postgres’ Original Project Goals: The Creators Totally Nailed It ^[35] / Как исходные цели проекта Postgres определили его успех ^[36]

В блоге Crunchy Data ^[35] в сентябре появилась статья ^[35] Элизабет Кристенсен (Elizabeth Christensen), подводящая итоги: все постгресовые цели достигнуты. Будем считать, что эта статья – фальстарт, а сейчас, впритык перед Новым Годом, самое время вернуться к этому жанру. На хабре есть перевод ^[36] этой статьи.

Начала Элизабет со статьи Майкла Стоунбрейкера и Лоуренса Роу (Michael Stonebraker & Lawrence A. Rowe) 1986 года: The Design of Postgres ^[37]. По её мнению создатели PostgreSQL справились со своей задачей идеально. Они создали гибкий каркас для широкого спектра сценариев использования в бизнесе системы, которая спустя тридцать лет стала самой популярной СУБД.

Чтобы далее показать, что все основные цели действительно пригвоздили (здесь: выполнили), она перечисляет 6 целей:

1. улучшенная поддержка сложных объектов, расширяющих сценарии использования в бизнесе и разработке;

2. обеспечение возможности расширения типов данных, операторов и способов доступа для пользователей;

3. предоставление средств для активных баз данных (например, уведомлений и триггеров);

4. упрощение процесса восстановления после сбоев;

5. использование преимуществ нового оборудования;

6. применение реляционной модели Кодда.

Дальше Элизабет рассматривает их с точки зрения ^[38] современных возможностей Postgres.

Напомним и о переводе Еленой Индрупской статьи Looking Back at Postgres ^[39] Джозефа Хеллерстайна (Joseph M. Hellerstein): Postgres в ретроспективе ^[40]. Она написана и переведена в начале 2019. Коллега Егор Рогов, опубликовавший перевод, предпослал ей такое замечание:

«программист, который отчаянно хотел построить систему с многоверсионностью» – судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.

Вадима можно увидеть в отчёте PGConf NYC 2025 Recap: Postgres Advances & Insights ^[41] команды EDB, об этом мы писали в Postgresso 9-10 (82-83) ^[42].

В статье Джозеф говорит не только о целях, но и о современных контекстах, например, о том, что технологические стеки больших данных 2000-х годов, включая феномен MapReduce, «много крови попортили» Стоунбрейкеру и ДеВитту (David DeWitt). О недостатках и попытках – удачных и неудачных – их исправления он говорит открыто:

Медленно работающее хранилище PostgreSQL не является внутренне присущим системе. В Greenplum ветка PostgreSQL в качестве интересной альтернативы интегрировала высокопроизводительное сжатое хранилище. Оно было разработано Мэттом МакКлином (Matt McCline)—ветераном команды Джима Грея (Jim Gray) в компании Tandem. Оно также не поддерживало темпоральных запросов.

NooData

Олег Бартунов, президент Postgres Professional (напомним, что гендир – Иван Панченко), начал понемногу обнародовать свой комплекс новых идей, объединённый им же изобретённым термином – NooData. Олег сделал доклад на эту тему “Эволюция ^[43] данных” на ММ25 ^[44] (ММ=МетаМаркетинг, мессидж конференции: для аналитиков, performance-маркетологов и product-менеджеров ^[44]), где рассказал о переходе к потоковой модели данных, которая обеспечит бесшовную работу и уберёт барьеры между СУБД, сервисами и инфраструктурой.

Это выступление, кажется, нигде не опубликовано, но у нас есть неиссякаемый источник: ЖЖ Олега. Там в посте От Big Data и Smart Data – к смысловым данным и ИИ-агентам ^[45] он поделился:

Переход [BigData => SmartData => NooData] особенно ясно виден на примере курьера. В модели Big Data он оставляет сотни GPS-точек – много, но бессмысленно. В модели Smart Data система вычисляет скорость, ETA и статус – полезнее, но всё ещё без объяснений. А в модели Noo Data система понимает, что курьер замедлился из-за пробки, прогнозирует задержку, оценивает риски для всех активных заказов и предлагает действие. Это новый тип данных: данные со смыслом, пригодные для ИИ-агентов.

<…>

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

Именно это приводит нас к realtime. Реалтайм – это не про скорость, а про сохранение смысловой связи между событием и моментом его возникновения. Как только данные становятся потоковыми, смысл должен появляться тогда же, иначе он становится запоздалым и бесполезным.

Упоминает Олег и NUMA-осознанную локальность; зональное лог-структурное хранение, естественно отражающее течение времени, и встроенную историю со смысловым контекстом, доступным ИИ-агентам ещё до фиксации данных в хранилище.

Об эволюции данных начали говорить уж точно до этого, но тогда ИИ-агенты ещё не сказали “иду на вы”.

Некто Даша Буланова в своём гитхабе ^[46] в 2021 пишет:

Вот два фундаментальных материала, которые помогут вам глубже погрузиться в теорию стриминга и понять ключевую разницу между пакетной и стриминговой обработкой с точки зрения времени. Они помогут вам сформулировать правильные вопросы, которые стоит задавать себе при работе с watermarks, triggers и windows. Эти статьи навсегда изменили моё понимание, и надеюсь, изменят ваше тоже.

Сами статьи написаны 10 лет назад. Вот эти статьи:

• Streaming 101: The world beyond batch ^[47].

• Streaming 102: The world beyond batch ^[48].

Обе на Радаре O’Reilly ^[49]. Автор статей – Тайлер Акидо (Tyler Akidau ^[50] – не японец), инженер в Google, сооснователь и коммитер Apache Beam ^[51]. Издатель также советует почитать Streaming Systems ^[52], авторы – тот же Тайлер, плюс: Слава Черняк и Рёвен Лакс (Slava Chernyak, Reuven Lax).

Я набрёл на них через статью 2021 года Эволюция данных: от больших к бесконечным ^[53] авторства Сергея Кедрова aka sergkedrov ^[54], основателя fabrique.ai – стартапа, не дожившего, судя по всему (рады будем ошибиться), до светлого ИИ-будущего. В статье Сергей пересказывает идеи Тайлера Акидо.

Кто кем погоняет?

В Postgresso 2 (63) ^[55] можно прочитать:

Hello DBOS – Announcing DBOS Cloud ^[56]: Майкл Стоунбрейкер объявил, что пора перевернуть пару ОС/СУБД вверх ногами: теперь не база будет поверх операционной системы, а наоборот: ОС поверх СУБД. Что в этом заявлении от маркетинга, а что от технологий, пока сказать трудно, но очевидно, что как минимум его DBOS (Database-Oriented Operating System ^[57]) с самого начала разрабатывалась для поддержки больших распределённых приложений в облаке, что ОС знает о том, что делается в базе ^[58], умеет путешествовать во времени (согласованно откатывать до заданного состояния), что архитектура бессерверная, все операции с данными ОС делаются транзакционно.

О текущем положение дел сказано ^[59] :

В марте 2024 года DBOS Cloud стал первым коммерческим сервисом от DBOS Inc. Он предоставляет транзакционные Functions as a Service ^[60] (FaaS) и позиционируется как конкурент serverless computing ^[61] архитектурам вроде AWS Lambda ^[62].

DBOS Cloud сейчас основан на PostgreSQL ^[63] и работает на сервисе микровиртуальных машин (microVM) Firecracker ^[64] от AWS. Поддерживает встроенные функции вроде масштабирования на несколько узлов и “машину времени” (time-traveler) отладчика, который помогает отслеживать неуловимые heisenbugs ^[65] и интегрирован в Visual Studio Code ^[66].

Ещё одна фича – надёжное выполнение: программа продолжает работать даже при перезапуске ОС, без повторения ^[67] уже выполненных работ.

Разве это не удивительно? Далее:

Firecracker запускается на урезанном Linux ^[68] микроядре ^[69] через урезанный KVM ^[70] гипервизор ^[71], так что части Linux-ядра всё ещё работают под капотом, но идёт работа по их устранению.

Чудны дела твои, Господи!

Но мы решили зайти с другой стороны – с Восточной. Понимая, конечно, что Восток – дело тонкое (и грубому нашему взгляду не очень понятное: понять можно не то).

Год назад в Postgresso #10-11 (71-72) ^[72] мы писали о Пигстае – Pigsty ^[73], странноватом проекте со странноватым названием “Свинарник” (Китай, кажется, в лидерах по потреблению свинины на душу, и там это уважаемое животное). Тема не даёт нам покоя и мы развернули её в Postgresso 9-10 (82-83) ^[42] в разделе Расширения, посткабанчик и свинка в свинарнике.

Проект раскрутил китайский разработчик Фен Руанг (Feng Ruohang), он же vonng. Похоже, что в основном он один там и трудится. И уж точно один пишет в блоге ^[74] Pigsty. Увы, они почему-то остановились в мае. Надеемся, что приостановились, что vonng отдохнёт и продолжит. Ведь он пишет там интересные вещи. Например, этот безусловно рукастый мастер прикрутил OrioleDB к Pigsty, разместив в своём Свинарнике. В OrioleDB is Here! 4x Performance, Zero Bloat, Decoupled Storage ^[75] он пишет:

Во время Qingming Festival (Цинмин ^[76]– праздник чистого света) я выпустил Pigsty v3.4.1 ^[77] со встроенным OrioleDB ^[78] и поддержкой ядра OpenHalo ^[79]. Теперь развернуть кластер OrioleDB так же просто, как и обычный PostgreSQL.

Теперь OrioleDB интегрирована в PG-экосистему – Patroni, pgBackRest, pg_exporter ^[80], pgbouncer – и всё запускается одним щелчком мыши.

А ведь OrioleDB (пока) не просто расширение, там требуется патчить ядро.

Не только рукастый, но и, безусловно, головастый: он читает и делает (китайские) транскрипты классиков – беседу, например, Майка Стоунбрейкера с Энди Павло: 2025 in Review with Mike Stonebraker and Andy Pavlo ^[81]. Из перевода с китайского мы узнаём, что Ши по тян (Shí pò tiān) – это почётное прозвище Стоунбрейкера в китайской IT-тусовке: “Камень, Разрушающий Небеса” (а может, это придумал Перплексити – тем лучше). И это уже имеет прямое отношение к тому, кто на ком сидит и кто кем погоняет – база на ОС или наоборот – транскрибируемое интервью размещено на сайте ^[82] (а вот гитхаб ^[83]) той самой DBOS.

И, наконец:

PGFS: Using PostgreSQL as a File System ^[84]

Там vanng пишет:

Недавно я получил интересный запрос от сообщества Odoo ^[85] (бывшая Tiny ERP, OpenERP). Они столкнулись с увлекательной задачей: «Раз базы данных умеют делать PITR (Point-in-Time Recovery), то можно ли откатывать так и файловую систему тоже?»

Да, можно. Если у вас есть база данных PostgreSQL (например, установленная через Pigsty), вы можете запустить PGFS всего несколькими командами.

Если мы примонтируем /var/lib/odoo к PGFS, все операции записи в файловую систему станут операциями записи в базу данных. База данных больше не хранит только SQL-данные – она хранит и информацию файловой системы. Это означает: при выполнении PITR не только база данных откатывается к конкретной точке во времени, но и файлы мгновенно откатываются вместе с базой данных к тому же заданному моменту.

Далее он берёт ОС, компатриотичную Pigsty, и провозглашает: Meet JuiceFS!

Её разработчики ^[86] (ох, как трудно с китайской транслитерацией, воздержусь на этот раз) вообще-то на Postgres не особенно ориентировались. Это опенсорсная распределённая ОС, совместимая с Elastic, с протоколами POSIX, HDFS и S3, мульти-облачная ^[87]. На их гитхабе ^[88] написано: метаданные файловой системы могут храниться в таких СУБД как Redis, MySQL и TiKV.

Ушлый vonng пишет (и делает): это чудо! Оказывается, JuiceFS поддерживает и PostgreSQL – как для хранения метаданных, так и для хранения объектов! Значит вы можете превратить любой экземплятр PostgreSQL в этакую “файловую систему”, просто переключив бэкэнд JuiceFS.

И демонстрирует, как это сделать. Но это не всё. Он пишет:

Кто-то может спросить: А разве ZFS не умеет делать снэпшоты? Да, ZFS может создавать и откатывать снэпшоты, но это всё равно привязано к конкретным моментам взятия снэпшотов. Для точного отката к конкретной секунде или минуте нужны настоящие решения на базе логов или возможности CDP (Continuous Data Protection). А комбинация JuiceFS+PG эффективно записывает логи операций с файлами в WAL базы данных, что PostgreSQL делает, естественно, отлично.

Я много хвалил Фена ^[89], поэтому он, надеюсь, не обидится, если (вдруг) увидит, что я украл позаимствовал у него эту картинку:

В заключение немного истории. Идея ОС поверх базы родилась не сейчас. Вот, например, статья Брайана Бартеломью (Brian Bartholomew) 1997 на Linux Journal ^[90]: Pgfs: The PostGres File System ^[91]. Возможно, это заслуживает отдельного разговора. По сути Pgfs – это транслятор NFS <-> SQL, говорит Брайан.

Но самое интересное, что такая ОС придумана и осуществлена в 1960 на IBM System/360 ^[92] и называется она Pick operating system ^[93] по имени изобретателя: его зовут Дик Пик (это не шутка: Dick Pick), его соавтор Дон Нельсон (Don Nelson).

Есть тут недопрояснённый нюанс: ОС поверх СУБД или ОС поверх СУБД, которая поверх ОС? DBAS Cloud намекают на 1-е: идёт работа по их (элементов ОС) устранению. Есть, в общем, над чем ещё думать и что искать.

Ещё интересное по теме:

The Cloud Outgrows Linux, And Sparks A New Operating System ^[94]

PGFs ^[95] от Darshan (forscht) ^[96].

Борьба с Postgres-предрассудками при помощи статей

Don’t give Postgres too much memory ^[97]

Томаш Вондра (Tomas Vondra) помогает разделаться с Postgres-предрассудками. Мол, вы думали: чем больше памяти – тем лучше? Только не в том случае, когда вы настраиваете maintenance_work_mem и work_mem. Томаш обращает внимание ^[98] на размер кэша процессора и то, как ОС распоряжается памятью.

Вы, допустим, увеличиваете maintenance_work_mem с 64MB до 16GB. И что же? А то, что создание индекса теперь медленней на 30%, сколько бы воркеров вы на запустили. Чудеса да и только. Но объяснимые – Томашем – чудеса.

История поиска бага в ядре Linux длиной в год, или нежданные нули из XFS’а ^[99]

Loxmatiy Mamont ^[100], опираясь на опыт ^[101] инженеров Postgres Professional, в большой статье с уровнем “Сложный”, говорит о многом, следуя сюжету, протяжённостью в год. А предрассудок – вот он:

Из нашего исследования вы узнаете, почему PostgreSQL (и любое другое приложение) может падать из-за бага в ядре Linux, при чём тут XFS и почему очистка памяти может быть не так полезна, как вы о ней думали.

К счастью, эти чудеса начинаются с ядра Linux 5.18 и благополучно заканчиваются в починенной версии 6.9.

VACUUM Is a Lie (About Your Indexes) ^[102]

На сайте с очаровательным названием boringSQL, созданном Радимом Мареком (Radim Marek), хозяин сайта тоже атакует Postgres-предрассудки:

Существует распространённое заблуждение, которое беспокоит многих разработчиков, использующих PostgreSQL: мол, настройте/запустите VACUUM – и ваша база данных останется здоровой. Мёртвые кортежи будут очищены. ID транзакций переработаны. Пространство освобождено. Ваша база данных будет жить счастливо вечно.

Но есть пара «грязных» секретов, о которых люди не знают. 1-й: VACUUM лжёт вам об ваших индексах. Хип похож на тетрис. Строки падают в любое доступное пространство, оставляя пробелы при удалении.

Что VACUUM не может сделать:

• Слить разреженные страницы вместе (может для пустых страниц).

• Уменьшить глубину дерева.

• Освободить пустые, но всё ещё связанные страницы.

• Изменить физическую структуру B-дерева.

Xип – это тетрис, там пробелы можно заполнить. Но B-дерево – это отсортированная книжная полка: VACUUM может вытащить книги, а сдвинуть оставшиеся ближе друг к другу но не может. При сканировании вы каждый раз ходите мимо пустых слотов. .

Большая техническая статья, вот её оглавление:

• Анатомия хранения.

• Эксперимент.

• Понять состояние страниц.

• Заметка о fillfactor.

• Почему планировщик обманывается.

• Полый индекс. REINDEX.

• pg_squeeze.

• VACUUM FULL.

• Когда действовать, а когда расслабиться.

• Заключение.

Перед Новым Годом особенно обращаем ваше внимание на предпоследний пункт. И желаем всем читателям расслабиться. По возможности.

Где спрятаться от вездесущих ИИ и AI? (спойлер: нигде)

10 самых перспективных стартапов с российскими основателями – 2025. Рейтинг Forbes ^[103]

Исследование Forbes ^[104], тут смесь объективных и субъективных критериев. Перспективные – это те, которые ещё не заматерели, единорогов ^[105] сюда не берут. Основан стартап должен быть в этой пятилетке.

Нет, стартапов с Postgres в этой десятке нет. База – есть, но векторная, она возглавляет список. Но хочется иногда выходить из комнаты постгресового контекста на улицу, чтобы осмотреться – в каком мире мы (уже!) живём.

Кто бы мог подумать: все стартапы из этого списка так или иначе связаны с ИИ :) А возглавляет список стартапов вот кто:

Qdrant ^[106]

Это разработчики векторной базы, то есть, понятное дело, для работы с ИИ. База написана на Rust. На гитхаб ^[107]е есть бенчмарки.

Основатели: Андрей Васнецов (Andrey Vasnetsov), Андре Заярни (André Zayarni), ключевые инвесторы: Spark Capital (инвестировал в Twitter, Slack, Trello и др.), IBB Ventures, Unusual Ventures – привлекли капитал $37,8 млн.

“Русскость” стартапов определяли в том числе по родному языку ключевых фигур, месту их рождения, учебы и работы. Андрей Васнецов окончил МГТУ им. Баумана и работал в «Тинькофф» (сейчас Т-Банк) старшим аналитиком-разработчиком в отделе Big Data и машинного обучения. В 2020-м Васнецов переехал в Берлин, получив офер от рекрутингового сервиса MoBerries. Там он возглавил отдел анализа данных. Васнецова не устраивала сторонняя векторная база данных, которую использовала MoBerries, так как в ней нельзя было задать параметры поиска. Например, указать, что компании нужны только немецкоговорящие специалисты. Разработчик создал свою систему управления векторными данными с настраиваемыми фильтрами — так появился Qdrant. Его партнером стал технический директор MoBerries Андре Заярни. Сейчас в компании больше 75 сотрудников в 20 странах. Базу неизменно включают в обзоры ведущих векторных баз.

Её включили в список установленных приложений отечественные хостеры Amvera Cloud ^[108] (они начинали с Heroku) и они пишут о ней на хабре: Всё про Qdrant. Обзор векторной базы данных ^[109].

В статье начинают с азов, потом переходят к архитектуре векторных СУБД и дальше конкретно к Qdrant:

В Qdrant все данные группируются в коллекции — это изолированные пространства хранения, в которых находятся векторы, точки и связанные с ними данные (payload). Если провести аналогию с реляционными БД, то коллекция — это как таблица, только для векторных и семантических данных.

У Квадранта (так произносится) есть собственное облако, а также он доступен на AWS, Google Cloud и Azure. И на Yandex Cloud ^[110].

Поехали дальше. Я решил коротко написать ещё о трёх стартапах из списка, хотя они к базам не имеют прямого отношения.

Aiphoria ^[111]

Это платформа для создания разговорных ИИ-агентов. Они умеют совершать и принимать звонки, писать сообщения и отвечать по электронной почте и в мессенджерах, а также оставлять комментарии в социальных сетях. По данным Aiphoria, ее виртуальными сотрудниками пользуются банки, телекоммуникационные и фармацевтические компании, онлайн-магазины, разработчики игр и другие предприятия – более 100 000 команд, или 50 млн ежемесячных пользователей.

Стартап основали бывший вице-президент Сбера Константин Круглов и Денис Чернилевский, в прошлом возглавлявший Яндекс Станцию. У компании есть офисы в Великобритании, ОАЭ, Португалии и на Кипре. В 2025 году она впервые привлекла $34 млн инвестиций по оценке $150 млн. Раунд возглавил сооснователь Veeam Software ^[112] Ратмир Тимашев.

Mirai AI ^[113]

Мираи – страшный червь ^[114] и одна из тойот ^[115]. А Mirai AI ^[113] – платформа для запуска и дообучения больших языковых моделей на гаджетах пользователей. Стартап запустили сооснователь нашумевшего в своё время фотосервиса Prisma ^[116] Алексей Моисеенков и сооснователь приложения Reface ^[117] Дмитрий Швец.

Ex-Human (Exh) AI ^[118]

Digital Humans & AI Agents for Business – цифровые аватары. Основатель: Артем Родичев, Ключевые инвесторы: a16z, Baidu Ventures, Soma Capital $ 3,7 млн.

Ex-Human – платформа для создания цифровых людей, с которыми, как заявлено на сайте компании, можно вести эмпатичные диалоги. Среди ангелов были сооснователь Tinder Джастин Матин и основатель ABBYY Давид Ян. Годовой доход (ARR) платформы составляет $8 млн, у стартапа более 1 млн пользователей и 60 B2B-клиентов.

PostGIS Day 2025 Recap: AI, Lakehouses and Geospatial Community ^[119]

Теперь, когда Crunchy стала частью озёрной Snowflake, Пол Рэмзи (Paul Ramsey ^[120]), папа PostGIS, пишет о PostGIS Day, им организованном уже под эгидой Снежинки. Соорганизатором была Элизабет Кристенсен (Elizabeth Christensen). Это 7-е по счёту мероприятие, прошедшее 20 ноября, изрядно переформатировали. Спикеров смогли пригласить “от Индии до Африки, от Европы до Северной Америки”, чему радуется Пол.

И говорили они в основном об ИИ – что он может внести полезного в PostGIS. Немало. Пол говорит:

Переходя от общих восторгов вокруг ИИ к практической реальности агентов, мы увидели инструменты от Felt, Carto и Bunting Labs, которые действительно могут писать в базу, выполнять и отлаживать пространственный SQL на лету. Мы также увидели, что архитектура lakehouse заняла центральное место, а PostGIS выступает уже не как изолированное хранилище данных, а, скорее, как высокопроизводительный коннектор к обширному миру объектного хранения, Iceberg и GeoParquet через такие инструменты, как pg_lake и Apache Sedona. И это были действующие проекты. Мы увидели, что пространственные агенты – это не просто чат-боты, галлюцинирующие SQL. Мы увидели их в системах, рассчитанных на итерации запросов.

Полный плейлист выступлений ^[121] на канале Snowflake ^[122].

Хорошо известный нам Дарафей Пролясковский (Darafei ‘Котяра’ Praliaskouski, Maumap ^[123]) и Альпер Динсер (Alper Dincer) рассказали об использовании гексагонов. Дарафей показал, как создавать конвейеры в PostGIS ^[124] и H3 ^[125] для моделирования mesh-сети LoRa Mestastic дорог и административных границ. Альпер показал, как drought.uk ^[126] – его платформа – использует ^[127] H3 для агрегации огромных климатических наборов данных, превращая тяжелую обработку растров в быстрые SQL-запросы, поддержанные индексами.

У Брендана Эшворта (Brendan Ashworth, Bunting Labs ^[128]) агент пишет запрос ^[129], разбирает сообщение об ошибке ^[130], если что-то пошло не так, исправляет его. Mundi ^[131] – WebGIS с ИИ – решает сложные пространственные задачи без участия человека. У Хайме Санчеса и Мамата Акеллы (Jaime Sanchez, Mamata Akella, Felt ^[132]) агенты прекрасно разбираются в расплывчатых понятиях “рядом” и “внутри”.

У Райана Миллера (Ryan Miller, Carto ^[133]) агент мог идентифицировать свободные земельные участки, фильтровать по экологическим ограничениям, а затем сохранять результаты обратно в базу данных Postgres.

Фавад Куреши (Fawad Qureshi, Snowflake) продемонстрировал, как  размываются границы ^[134] между транзакционными и аналитическими системами, как Snowflake и PostGIS могут обмениваться данными без копирования, позволяя тяжёлым аналитическим нагрузкам работать параллельно с операционными приложениями без конкуренции за ресурсы.

Building a RAG Server with PostgreSQL – Part 3: Deploying Your RAG API ^[135]

И ещё раз напоминаем о почти что манифесте Дейва Пейджа:

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

Не то, чтобы он разорвал все отношения с ИИ. Теперь вот рассказывает, как соорудить RAG-сервер, уютно расположив его между приложением и LLM.

В Части 1 ^[137] загрузили документацию в PostgreSQL. В Части 2 ^[138] разбили эти документы на чанки и сгенерировали векторные эмбеддинги. А в этой, в Части 3 ^[135], собирают всё вместе. Теперь есть простой HTTP API для вопросов, использующих собственную документацию вопрошающих.

pg_llm_helper 0.1.0 – Troubleshooting errors with OpenAI’s gpt-4o-mini model ^[139]

Автор расширения – Джёф Монти (Geoff Montee ^[140]). Оно интегрирует модель gpt-4o-mini (OpenAI) прямо в PostgreSQL, что может помочь отслеживанию ошибок.

ПиДжи & ЭйАй от Савелия

Safreliy ^[141] написал уже 14 статей на эту тему на Хабре. Мы следили ^[72] с самого начала. Отрекомендовался Сафрелий-Савелий Батурин следующим образом: программист-математик ^[141] (в Postgres Professional). Начнём в обратном хронологическом порядке:

Выбор LLM и фреймворка для ИИ-агентов ^[142]

Статья технологичная и специализированная: много терминов и незнакомых (мне) аббревиатур.

Сначала Савелий перечисляет дюжину задач, которые ставили перед ИИ-командой. Вот, например, задача #4:

Graph-RAG-агент над большой кодовой базой на C (ИИ-Copilot). Ядро PostgreSQL и сопутствующие проекты – это миллионы строк C-кода. Мы строим граф знаний в Apache AGE: вершины – директории, файлы, функции, структуры, макросы, переменные; рёбра — вложенные зависимости и вызовы. Агент поверх этого графа отвечает на вопросы о том, где реализовано вот это поведение ^[143], чем чревато изменение такого-то участка и помогает с навигацией по коду как по базе знаний, а не как по сплошному тексту с поиском.

А вот #6:

Генератор hint-сетов для PostgreSQL. Здесь в центре всего расширение pg_hint_plan. Модель видит запрос, статистику, индексы и предлагает подсказки в формате hint-сетов. Обучаем это дело при помощи GRPO, параллельно зажимаем формат подсказок формальной грамматикой [да! см. ниже], чтобы pg_hint_plan мог их распарсить и применить.

По этому пункту есть разъяснение: hint-сеты: где дообучение действительно оправдано [так как 90% задач решается “из коробки”]:

Дообучение у нас оправдано в двух случаях:

1. когда нужна небольшая модель под конкретный сценарий, например, on-prem у клиента, где нет мощных GPU.

2. когда требуется очень специфичный формат вывода, который трудно стабильно выжать из модели одними промптами.

Ну и выборы: как пришли к текущему стеку: vLLM, Qwen3-Next-80B и свой агентный слой.

Пропустим статью Как мы обеспечили +33% к точности на сложных SQL-запросах ^[144], и немного задержимся на:

Будущее ИИ — формальные грамматики ^[145]

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

1. Фонемы ограничивают сочетания звуков. В русском языке, например, их всего 42.

2. Слова ограничивают сочетания фонем и переводят наш мир в дискретное множество понятий — так рождается семантика.

3. Предложения, в свою очередь, ограничивают сочетания слов, создавая структуры для описания явлений воспринимаемого нами мира.

Все эти ограничения составляют суть языка, его синтаксис и семантику.

К нашему счастью, человеческий язык не такая уж строгая система. Но это постановки задачи не отменяет. Ох, просим прощения, дальше следует разъяснение автора:

Наш язык всё ещё остаётся излишне свободным и эту свободу большие языковые модели с лёгкостью перенимают.

Дальше – изрядная программистско-математическая заумь, которую мы здесь воспроизводить не будем: всё же Новый год на носу.

Вместо этого перенесёмся в самое начало писательской карьеры Сафрелия на хабре:

Нейронные оптимизаторы запросов в реляционных БД (Часть 3): Погружение в ранжирование ^[146]

Нейронные оптимизаторы запросов в реляционных БД (Часть 2): На пути к продуктивизации ^[147]

Нейронные оптимизаторы запросов в реляционных БД (Часть 1) ^[148]

VectorChord 1.0.0 ^[149]

Разработчик – TensorChord (в Postgresso #2 за этот год ^[150] есть даже портрет сооснователя этой компании, где замечены только сотрудники с китайскими фамилиями).

VectorChord ^[151] совместим с типами данных и синтаксисом pgvector, но использует индекс IVF (Inverted File Index) и квантование RaBitQ для дополнительной производительности как при индексации, так и при поиске. Претендует на умение «хранить в 26 раз больше векторов, чем pgvector, за ту же цену».

Это наследник их же разработки pgvecto.rs ^[152]. Теперь вот юбилейный VectorChord 1.0.0 ^[149]. А не так давно, в сентябре был ещё VectorChord 0.5.3 ^[153]. Документация здесь ^[149].

Introduction – PostgreSQL AI Query Extension ^[154] (pg_ai_query)

Это расширение, которое принимает запросы на естественном языке, и на лету преобразует их в SQL, используя модели OpenAI либо Anthropic. Гитхаб ^[155] здесь. Разработчик – Сачин Бенодивал (Sachin Beniwal, benodiwal ^[156]) из Бангалора. В README ^[157] много примеров.

Короче:

1-2-3-4-5, я [ИИ] иду искать. Кто не спрятался – я [ИИ] не виноват [?].

Ещё конференции

PGPro TechDay 2026 ^[158]

Не путать с PGConf.Russia, о которой ниже. PGPro TechDay ^[158] фокусируется на произведениях Postgres Professional. Пройдёт уже 27 января в Москве в гостинице “Рэдиссон Славянская” на площади Евразии ^[159] (бывшей площади Европы).

Кроме главного конференц-зала, который отдадут тематике Postgres Pro Enterprise 18.1.1 ^[1], доклады пройдут в зале “Толстой” – его отдали аналитическим решениям:

Postgres Pro Axe: Аналитическая СУБД от Postgres Pro. Просто добавь OLAP ^[160] – Андрей Кулага (Postgres Professional).

AXE это не только топор, но и Analitical aXElerator. Pgpro_axe – это расширение, работающее с Postgres Pro Enterprise. Оно оптимально для работы с большими и гибридными нагрузками без перехода на MPP. Область применения – OLTP и большие OLAP (а Tengri, о которой подробно расскажем уже в январе, – для работы с очень большими OLAP). AXE ориентирована на файлы parquet на S3 или локально.

Советую не забывать ^[161] и о зале “Пушкин”, где пройдут воркшопы. Например, по тому же AXE будет проводить воркшоп Денис Гидин (тоже, конечно, Postgres Professional): Postgres Pro AXE — колоночный векторный сверхбыстрый инструмент для аналитики ^[160].

Будут работать стенды с демонстрациями ключевых продуктов и сервисов Postgres Professional:

• Postgres Pro Enterprise 18,

• Shardman – распределенная реляционная СУБД,

• ProGate – комплексное решение для миграции и репликации данных с автоматизацией ключевых этапов работы.

• Ask Postgres – AI-ассистент для работы с базами данных,

• Professional Services по внедрению, сопровождению и развитию решений.

PGConf.Russia 2026 ^[162]

Состоится 23 – 24 марта 2026 в World Trade Centr ^[163] (Москва, Краснопресненская наб., 12, вход №4). Открыты регистрация ^[164], заявки на доклады ^[165] и мастер-классы ^[166].

A Meetup Quiz? ^[167] (Брюс о разных постгресовых ивентах)

Это постгресовая часть блога Брюса Момджана. Из короткой заметки мы узнаём, что Брюс за год поучаствовал в более 100 Postgres-ивентах. Остановиться поподробней он решил на Armenia PostgreSQL User Group meetup ^[168], который организовала Эмма Сароян (Emma Saroyan ^[169]). Она очаровала Брюса оригинальностью замысла митапа: после его лекции она устроила мобильный квиз.

Ещё Брюс пишет “о недавней конференции в Риге” – то есть прошлогодней PGConf.eu ^[170]. Но заходит с неожиданной стороны. Он решил остановиться на панельной дискуссии How to Work with Other Postgres People. ^[171]

Другие – это да, те самые: люди с Mental Health issues.

Тема интересная, но я не читал описание, и содержание меня удивило. Выступавшие откровенно говорили о своих трудностях в общении с другими, и это побудило аудиторию тоже быть открытой и делиться впечатлениями ^[172]. Для меня это было больше похоже на церковное молитвенное собрание, чем на доклад. Я сказал: такие доклады должны быть на каждой конференции.

Блог Брюса раздваивается на Postgres ^[173] и Вообще ^[174]. В порядке исключения заглянем и в Вообще – чем ещё интересуются Postgres-классики?

Ого! Suicide and Responsibility ^[175] – самоубийство ^[176] и ответственность:

Брюс прочитал статью ^[177] в Atlantic о легализации в Канаде медпомощи в умирании (medical assistance in dying – MAID) и пишет по этому поводу:

Но существует другая версия либерализма [кроме той, где жизнь полная собственность живущего – “что хочу, то с ней и делаю” – поэтому, по этой версии, мешать самоубийству – преступление]. Назовём это либерализмом, основанным на дарах. Он начинается с иной базы: я – получатель даров. Я получил множество даров от тех, кто был до меня, включая сам дар жизни. Суть жизни – не в стремлении к индивидуальному счастью. Суть жизни – в реализации даров, которые мне дали мои предки, и в передаче их, должным образом улучшенных, тем, кто придёт после.

Хм, как-то не новогодне получилось. Но смысл-то жизнеутверждающий! Пусть останется – в уходящем году.

What Postgres developers can expect from ^[178]PGConf.dev ^[179]

Это Мелани Плейгман (Melanie Plageman) делится своими ожиданиями в подкасте Talking Postgres with Claire Giordano ^[180]. PGConf.dev ^[179] 2026 ^[181] пройдёт 19-22 мая в Ванкувере в кампусе Университета Саймона Фрейзера ^[182]. Приём заявок на доклады ^[183] действует до 16 января.

Перенесёмся опять в прошлое, чтобы насладиться

Postgres Trip Summary from PGConf EU 2025 (with lots of photos) ^[184]

Отчёт Клэр Джордано (Claire Giordano) на Microsoft Community Hub ^[184]. Всё так и есть: очень много фотографий!

---

На этом на сегодня всё. Точнее: всё в 2025. Встретимся в 2026. С НАСТУПАЮЩИМ!