Postgres Pro Enterprise 18.1.1
До Нового Года успела выйти 18-я версия Postgres Pro Enterprise. Полный список нового слишком велик для нашего жанра. Вот избранное.
Добавлена возможность создавать таблицы, которые разделяются на секции при помощи внешнего ключа. Внешний ключ используется как ссылка на родительскую секционированную таблицу и определяется в предложении
PARTITION BY REFERENCE.Обновлены модули, в том числе BiHA. В ней много важных изменений:
Расширение biha обновлено до версии 1.7.
Появилась экспериментальная функциональность, позволяющая объединять узлы BiHA-кластера в сегменты (логические узлы), которые можно разместить в географически распределённых центрах обработки данных. Подробности в разделе Геораспределённость и катастрофоустойчивость.
Добавлен специальный защитный механизм watchdog, который помогает предотвратить зависание узлов и проблему разделения кластера (split-brain). Механизмом
watchdogможно управлять с помощью параметра конфигурации biha.watchdog_timeout.
В расширение proxima добавлен экспериментальный модуль KVik. Модуль KVik предназначен для систем с высокой нагрузкой на чтение данных. Он кеширует в оперативной памяти данные баз данных Postgres Pro и обеспечивает быструю работу с ними через протокол RESP (Redis Serialization Protocol). Основные возможности KVik:
высокопроизводительное чтение данных;
поддержка команд RESP, таких как
SET,GET,DEL;автоматическое аннулирование данных в кеше при их изменении в базах данных Postgres Pro операторами
INSERT,UPDATE,DELETE;автоматическое изменение данных в базах данных Postgres Pro при их изменении в кеше операциями
SETиDEL.
Модуль AQO (Adaptive Query Optimizer) 4.0 использует машинное обучение для автоматического исправления ошибок в планах выполнения запросов, возникающих в стандартном планировщике. Гитхаб AQO.
Изменено поведение AQE (адаптивное выполнение запросов). Теперь для работы AQE необходимо для параметра конфигурации compute_plan_id установить значение
auto(по умолчанию) илиon, в противном случае AQE отключено.В расширении pgpro_multiplan похожие изменения. Теперь, чтобы включить вычисление идентификаторов планов в ядре, которое используется в pgpro_stats, для параметра конфигурации compute_plan_id необходимо установить значение
on. В противном случае все значения поля равны0.Усовершенствован поиск k-NN.
Более либеральная политика паролей: добавлены новые параметры
OLD_PASSWORD_TIMEиOLD_PASSWORD_MAXдля командCREATE PROFILEиALTER PROFILE. Теперь какое-то (заданное) время можно пользоваться и новым и старым паролями (подробности, в т. ч. о других параметрах - в документации Postgres Pro Standard 18.0.1.Обновлены: apache_age до 1.6.1, orafce до 4.16.3, pg_filedump до 18.1, pg_hint_plan до 1.8.0.1, pg_probackup до 2.8.12 Enterprise, pgpro_controldata до 18.2.0, pgpro-orautl до 2.2, pgvector до 0.8.1, tds_fdw до 2.0.5 и другие модули и утилиты.
Асинхронный ввод-вывод (AIO).
Оптимизация SkipScan.
Расширенные инструменты мониторинга.
Эффективный Vacuum.
На CNews вышла статья, где новшества вполне складно изложены и акценты адекватно расставлены:
Новые контрибьюторы
Появилось 12 новых контрибьюторов - не major contributors, но и не просто contributors: с совсем недавних пор, после обсуждения в рассылке 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 Андреаса Шербаума (Andreas Scherbaum).
Dirk Krautschick - старший архитектор решений (senior solution architect) в Aiven, живёт в Германии. Но он не совсем немец, он бейсиканец: real native language is in fact not German but BASIC. Он до сих пор в сообществе Oracle, хотя чаще работает с Postgres.
Полина Бунгина (Polina Bungina)
Инженер баз данных PostgreSQL в Zalando, живёт в Берлине. Из Санкт-Петербурга. Начинала работу с базами с Greenplum 5. Сейчас в основном работает над Patroni, а также контибьютит в Spilo (Postgres-оператор от Zalando) и некоторые расширения.
Кроме того Полина ещё большая шутница (шутникесса?), чем Дирк. Она, например, признаётся, что её хобби:
макияж,
преступления (true crimes) и
авиакатастрофы.
Некоторые из них я практикую, а о других только читаю или слушаю подкасты…
На всякий я спросил у Перплексити: она шутит?
"Да, - сказал он (или она? или оно?) - она говорит это в ироничном ключе, создавая абсурдный контраст между безобидным хобби и мрачными темами." - и от сердца отлегло.
Кстати, в этом номере мы решили не подводить итоги года, а наоборот: больше напоминать об идеях, которые, возникнув, может быть, раньше, устремились в будущее. И контекст мы временно расширяем, не ограничиваясь базами и даже ИТ.
(Почти) Postgres-философия
Postgres’ Original Project Goals: The Creators Totally Nailed It / Как исходные цели проекта Postgres определили его успех
В блоге Crunchy Data в сентябре появилась статья Элизабет Кристенсен (Elizabeth Christensen), подводящая итоги: все постгресовые цели достигнуты. Будем считать, что эта статья - фальстарт, а сейчас, впритык перед Новым Годом, самое время вернуться к этому жанру. На хабре есть перевод этой статьи.
Начала Элизабет со статьи Майкла Стоунбрейкера и Лоуренса Роу (Michael Stonebraker & Lawrence A. Rowe) 1986 года: The Design of Postgres. По её мнению создатели PostgreSQL справились со своей задачей идеально. Они создали гибкий каркас для широкого спектра сценариев использования в бизнесе системы, которая спустя тридцать лет стала самой популярной СУБД.
Чтобы далее показать, что все основные цели действительно пригвоздили (здесь: выполнили), она перечисляет 6 целей:
улучшенная поддержка сложных объектов, расширяющих сценарии использования в бизнесе и разработке;
обеспечение возможности расширения типов данных, операторов и способов доступа для пользователей;
предоставление средств для активных баз данных (например, уведомлений и триггеров);
упрощение процесса восстановления после сбоев;
использование преимуществ нового оборудования;
применение реляционной модели Кодда.
Дальше Элизабет рассматривает их с точки зрения современных возможностей Postgres.
Напомним и о переводе Еленой Индрупской статьи Looking Back at Postgres Джозефа Хеллерстайна (Joseph M. Hellerstein): Postgres в ретроспективе. Она написана и переведена в начале 2019. Коллега Егор Рогов, опубликовавший перевод, предпослал ей такое замечание:
«программист, который отчаянно хотел построить систему с многоверсионностью» - судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.
Вадима можно увидеть в отчёте PGConf NYC 2025 Recap: Postgres Advances & Insights команды EDB, об этом мы писали в Postgresso 9-10 (82-83).
В статье Джозеф говорит не только о целях, но и о современных контекстах, например, о том, что технологические стеки больших данных 2000-х годов, включая феномен MapReduce, «много крови попортили» Стоунбрейкеру и ДеВитту (David DeWitt). О недостатках и попытках - удачных и неудачных - их исправления он говорит открыто:
Медленно работающее хранилище PostgreSQL не является внутренне присущим системе. В Greenplum ветка PostgreSQL в качестве интересной альтернативы интегрировала высокопроизводительное сжатое хранилище. Оно было разработано Мэттом МакКлином (Matt McCline)—ветераном команды Джима Грея (Jim Gray) в компании Tandem. Оно также не поддерживало темпоральных запросов.
NooData
Олег Бартунов, президент Postgres Professional (напомним, что гендир - Иван Панченко), начал понемногу обнародовать свой комплекс новых идей, объединённый им же изобретённым термином - NooData. Олег сделал доклад на эту тему "Эволюция данных" на ММ25 (ММ=МетаМаркетинг, мессидж конференции: для аналитиков, performance-маркетологов и product-менеджеров), где рассказал о переходе к потоковой модели данных, которая обеспечит бесшовную работу и уберёт барьеры между СУБД, сервисами и инфраструктурой.
Это выступление, кажется, нигде не опубликовано, но у нас есть неиссякаемый источник: ЖЖ Олега. Там в посте От Big Data и Smart Data - к смысловым данным и ИИ-агентам он поделился:
Переход [BigData => SmartData => NooData] особенно ясно виден на примере курьера. В модели Big Data он оставляет сотни GPS-точек - много, но бессмысленно. В модели Smart Data система вычисляет скорость, ETA и статус - полезнее, но всё ещё без объяснений. А в модели Noo Data система понимает, что курьер замедлился из-за пробки, прогнозирует задержку, оценивает риски для всех активных заказов и предлагает действие. Это новый тип данных: данные со смыслом, пригодные для ИИ-агентов.
<...>
В классических системах время обычно превращали в поле timestamp, а архитектура оставалась безвременной. Такой подход работал, пока данные поступали редко и большими порциями. Сегодня ситуация изменилась: данные приходят как поток различий, непрерывно и с высокой плотност��ю во времени. Как только дискретность стала потоковой, время перестало быть второстепенным атрибутом и вновь соединяется с данными как их несущая координата. Если интерпретацию события отложить, теряется причинность, а вместе с ней - возможность действовать.
Именно это приводит нас к realtime. Реалтайм - это не про скорость, а про сохранение смысловой связи между событием и моментом его возникновения. Как только данные становятся потоковыми, смысл должен появляться тогда же, иначе он становится запоздалым и бесполезным.
Упоминает Олег и NUMA-осознанную локальность; зональное лог-структурное хранение, естественно отражающее течение времени, и встроенную историю со смысловым контекстом, доступным ИИ-агентам ещё до фиксации данных в хранилище.
Об эволюции данных начали говорить уж точно до этого, но тогда ИИ-агенты ещё не сказали "иду на вы".
Некто Даша Буланова в своём гитхабе в 2021 пишет:
Вот два фундаментальных материала, которые помогут вам глубже погрузиться в теорию стриминга и понять ключевую разницу между пакетной и стриминговой обработкой с точки зрения времени. Они помогут вам сформулировать правильные вопросы, которые стоит задавать себе при работе с watermarks, triggers и windows. Эти статьи навсегда изменили моё понимание, и надеюсь, изменят ваше тоже.
Сами статьи написаны 10 лет назад. Вот эти статьи:
Обе на Радаре O’Reilly. Автор статей - Тайлер Акидо (Tyler Akidau - не японец), инженер в Google, сооснователь и коммитер Apache Beam. Издатель также советует почитать Streaming Systems, авторы - тот же Тайлер, плюс: Слава Черняк и Рёвен Лакс (Slava Chernyak, Reuven Lax).
Я набрёл на них через статью 2021 года Эволюция данных: от больших к бесконечным авторства Сергея Кедрова aka sergkedrov, основателя fabrique.ai - стартапа, не дожившего, судя по всему (рады будем ошибиться), до светлого ИИ-будущего. В статье Сергей пересказывает идеи Тайлера Акидо.
Кто кем погоняет?
В Postgresso 2 (63) можно прочитать:
Hello DBOS - Announcing DBOS Cloud: Майкл Стоунбрейкер объявил, что пора перевернуть пару ОС/СУБД вверх ногами: теперь не база будет поверх операционной системы, а наоборот: ОС поверх СУБД. Что в этом заявлении от маркетинга, а что от технологий, пока сказать трудно, но очевидно, что как минимум его DBOS (Database-Oriented Operating System) с самого начала разрабатывалась для поддержки больших распределённых приложений в облаке, что ОС знает о том, что делается в базе, умеет путешествовать во времени (согласованно откатывать до заданного состояния), что архитектура бессерверная, все операции с данными ОС делаются транзакционно.
О текущем положение дел сказано :
В марте 2024 года DBOS Cloud стал первым коммерческим сервисом от DBOS Inc. Он предоставляет транзакционные Functions as a Service (FaaS) и позиционируется как конкурент serverless computing архитектурам вроде AWS Lambda.
DBOS Cloud сейчас основан на PostgreSQL и работает на сервисе микровиртуальных машин (microVM) Firecracker от AWS. Поддерживает встроенные функции вроде масштабирования на несколько узлов и "машину времени" (time-traveler) отладчика, который помогает отслеживать неуловимые heisenbugs и интегрирован в Visual Studio Code.
Ещё одна фича - надёжное выполнение: программа продолжает работать даже при перезапуске ОС, без повторения уже выполненных работ.
Разве это не удивительно? Далее:
Firecracker запускается на урезанном Linux микроядре через урезанный KVM гипервизор, так что части Linux-ядра всё ещё работают под капотом, но идёт работа по их устранению.
Чудны дела твои, Господи!
Но мы решили зайти с другой стороны - с Восточной. Понимая, конечно, что Восток - дело тонкое (и грубому нашему взгляду не очень понятное: понять можно не то).
Год назад в Postgresso #10-11 (71-72) мы писали о Пигстае - Pigsty, странноватом проекте со странноватым названием "Свинарник" (Китай, кажется, в лидерах по потреблению свинины на душу, и там это уважаемое животное). Тема не даёт нам покоя и мы развернули её в Postgresso 9-10 (82-83) в разделе Расширения, посткабанчик и свинка в свинарнике.
Проект раскрутил китайский разработчик Фен Руанг (Feng Ruohang), он же vonng. Похоже, что в основном он один там и трудится. И уж точно один пишет в блоге Pigsty. Увы, они почему-то остановились в мае. Надеемся, что приостановились, что vonng отдохнёт и продолжит. Ведь он пишет там интересные вещи. Например, этот безусловно рукастый мастер прикрутил OrioleDB к Pigsty, разместив в своём Свинарнике. В OrioleDB is Here! 4x Performance, Zero Bloat, Decoupled Storage он пишет:
Во время Qingming Festival (Цинмин - праздник чистого света) я выпустил Pigsty v3.4.1 со встроенным OrioleDB и поддержкой ядра OpenHalo. Теперь развернуть кластер OrioleDB так же просто, как и обычный PostgreSQL.
Теперь OrioleDB интегрирована в PG-экосистему - Patroni, pgBackRest, pg_exporter, pgbouncer - и всё запускается одним щелчком мыши.
А ведь OrioleDB (пока) не просто расширение, там требуется патчить ядро.
Не только рукастый, но и, безусловно, головастый: он читает и делает (китайские) транскрипты классиков - беседу, например, Майка Стоунбрейкера с Энди Павло: 2025 in Review with Mike Stonebraker and Andy Pavlo. Из перевода с китайского мы узнаём, что Ши по тян (Shí pò tiān) - это почётное прозвище Стоунбрейкера в китайской IT-тусовке: "Камень, Разрушающий Небеса" (а может, это придумал Перплексити - тем лучше). И это уже имеет прямое отношение к тому, кто на ком сидит и кто кем погоняет - база на ОС или наоборот - транскрибируемое интервью размещено на сайте (а вот гитхаб) той самой DBOS.
И, наконец:
PGFS: Using PostgreSQL as a File System
Там vanng пишет:
Недавно я получил интересный запрос от сообщества Odoo (бывшая Tiny ERP, OpenERP). Они столкнулись с увлекательной задачей: «Раз базы данных умеют делать PITR (Point-in-Time Recovery), то можно ли откатывать так и файловую систему тоже?»
Да, можно. Если у вас есть база данных PostgreSQL (например, установленная через Pigsty), вы можете запустить PGFS всего несколькими командами.
Если мы примонтируем /var/lib/odoo к PGFS, все операции записи в файловую систему станут операциями записи в базу данных. База данных больше не хранит только SQL-данные - она хранит и информацию файловой системы. Это означает: при выполнении PITR не только база данных откатывается к конкретной точке во времени, но и файлы мгновенно откатываются вместе с базой данных к тому же заданному моменту.
Далее он берёт ОС, компатриотичную Pigsty, и провозглашает: Meet JuiceFS!
Её разработчики (ох, как трудно с китайской транслитерацией, воздержусь на этот раз) вообще-то на Postgres не особенно ориентировались. Это опенсорсная распределённая ОС, совместимая с Elastic, с протоколами POSIX, HDFS и S3, мульти-облачная. На их гитхабе написано: метаданные файловой системы могут храниться в таких СУБД как Redis, MySQL и TiKV.
Ушлый vonng пишет (и делает): это чудо! Оказывается, JuiceFS поддерживает и PostgreSQL - как для хранения метаданных, так и для хранения объектов! Значит вы можете превратить любой экземплятр PostgreSQL в этакую "файловую систему", просто переключив бэкэнд JuiceFS.
И демонстрирует, как это сделать. Но это не всё. Он пишет:
Кто-то может спросить: А разве ZFS не умеет делать снэпшоты? Да, ZFS может создавать и откатывать снэпшоты, но это всё равно привязано к конкретным моментам взятия снэпшотов. Для точного отката к конкретной секунде или минуте нужны настоящие решения на базе логов или возможности CDP (Continuous Data Protection). А комбинация JuiceFS+PG эффективно записывает логи операций с файлами в WAL базы данных, что PostgreSQL делает, естественно, отлично.
Я много хвалил Фена, поэтому он, надеюсь, не обидится, если (вдруг) увидит, что я украл позаимствовал у него эту картинку:
В заключение немного истории. Идея ОС поверх базы родилась не сейчас. Вот, например, статья Брайана Бартеломью (Brian Bartholomew) 1997 на Linux Journal: Pgfs: The PostGres File System. Возможно, это заслуживает отдельного разговора. По сути Pgfs - это транслятор NFS <-> SQL, говорит Брайан.
Но самое интересное, что такая ОС придумана и осуществлена в 1960 на IBM System/360 и называется она Pick operating system по имени изобретателя: его зовут Дик Пик (это не шутка: Dick Pick), его соавтор Дон Нельсон (Don Nelson).
Есть тут недопрояснённый нюанс: ОС поверх СУБД или ОС поверх СУБД, которая поверх ОС? DBAS Cloud намекают на 1-е: идёт работа по их (элементов ОС) устранению. Есть, в общем, над чем ещё думать и что искать.
Ещё интересное по теме:
The Cloud Outgrows Linux, And Sparks A New Operating System
Борьба с Postgres-предрассудками при помощи статей
Don't give Postgres too much memory
Томаш Вондра (Tomas Vondra) помогает разделаться с Postgres-предрассудками. Мол, вы думали: чем больше памяти - тем лучше? Только не в том случае, когда вы настраиваете maintenance_work_mem и work_mem. Томаш обращает внимание на размер кэша процессора и то, как ОС распоряжается памятью.
Вы, допустим, увеличиваете maintenance_work_mem с 64MB до 16GB. И что же? А то, что создание индекса теперь медленней на 30%, сколько бы воркеров вы на запустили. Чудеса да и только. Но объяснимые - Томашем - чудеса.
История поиска бага в ядре Linux длиной в год, или нежданные нули из XFS'а
Loxmatiy Mamont, опираясь на опыт инженеров Postgres Professional, в большой статье с уровнем "Сложный", говорит о многом, следуя сюжету, протяжённостью в год. А предрассудок - вот он:
Из нашего исследования вы узнаете, почему PostgreSQL (и любое другое приложение) может падать из-за бага в ядре Linux, при чём тут XFS и почему очистка памяти может быть не так полезна, как вы о ней думали.
К счастью, эти чудеса начинаются с ядра Linux 5.18 и благополучно заканчиваются в починенной версии 6.9.
VACUUM Is a Lie (About Your Indexes)
На сайте с очаровательным названием boringSQL, созданном Радимом Мареком (Radim Marek), хозяин сайта тоже атакует Postgres-предрассудки:
Существует распространённое заблуждение, которое беспокоит многих разработчиков, использующих PostgreSQL: мол, настройте/запустите VACUUM - и ваша база данных останется здоровой. Мёртвые кортежи будут очищены. ID транзакций переработаны. Пространство освобождено. Ваша база данных будет жить счастливо вечно.
Но есть пара «грязных» секретов, о которых люди не знают. 1-й: VACUUM лжёт вам об ваших индексах. Хип похож на тетрис. Строки падают в любое доступное пространство, оставляя пробелы при удалении.
Что VACUUM не может сделать:
Слить разреженные страницы вместе (может для пустых страниц).
Уменьшить глубину дерева.
Освободить пустые, но всё ещё связанные страницы.
Изменить физическую структуру B-дерева.
Xип - это тетрис, там пробелы можно заполнить. Но B-дерево - это отсортированная книжная полка: VACUUM может вытащить книги, а сдвинуть оставшиеся ближе друг к другу но не может. При сканировании вы каждый раз ходите мимо пустых слотов. .
Большая техническая статья, вот её оглавление:
Анатомия хранения.
Эксперимент.
Понять состояние страниц.
Заметка о fillfactor.
Почему планировщик обманывается.
Полый индекс. REINDEX.
pg_squeeze.
VACUUM FULL.
Когда действовать, а когда расслабиться.
Заключение.
Перед Новым Годом особенно обращаем ваше внимание на предпоследний пункт. И желаем всем читателям расслабиться. По возможности.
Где спрятаться от вездесущих ИИ и AI? (спойлер: нигде)
10 самых перспективных стартапов с российскими основателями - 2025. Рейтинг Forbes
Исследование Forbes, тут смесь объективных и субъективных критериев. Перспективные - это те, которые ещё не заматерели, единорогов сюда не берут. Основан стартап должен быть в этой пятилетке.
Нет, стартапов с Postgres в этой десятке нет. База - есть, но векторная, она возглавляет список. Но хочется иногда выходить из комнаты постгресового контекста на улицу, чтобы осмотреться - в каком мире мы (уже!) живём.
Кто бы мог подумать: все стартапы из этого списка так или иначе связаны с ИИ :) А возглавляет список стартапов вот кто:
Это разработчики векторной базы, то есть, понятное дело, для работы с ИИ. База написана на Rust. На гитхабе есть бенчмарки.
Основатели: Андрей Васнецов (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 (они начинали с Heroku) и они пишут о ней на хабре: Всё про Qdrant. Обзор векторной базы данных.
В статье начинают с азов, потом переходят к архитектуре векторных СУБД и дальше конкретно к Qdrant:
В Qdrant все данные группируются в коллекции — это изолированные пространства хранения, в которых находятся векторы, точки и связанные с ними данные (payload). Если провести аналогию с реляционными БД, то коллекция — это как таблица, только для векторных и семантических данных.
У Квадранта (так произносится) есть собственное облако, а также он доступен на AWS, Google Cloud и Azure. И на Yandex Cloud.
Поехали дальше. Я решил коротко написать ещё о трёх стартапах из списка, хотя они к базам не имеют прямого отношения.
Это платформа для создания разговорных ИИ-агентов. Они умеют совершать и принимать звонки, писать сообщения и отвечать по электронной почте и в мессенджерах, а также оставлять комментарии в социальных сетях. По данным Aiphoria, ее виртуальными сотрудниками пользуются банки, телекоммуникационные и фармацевтические компании, онлайн-магазины, разработчики игр и другие предприятия - более 100 000 команд, или 50 млн ежемесячных пользователей.
Стартап основали бывший вице-президент Сбера Константин Круглов и Денис Чернилевский, в прошлом возглавлявший Яндекс Станцию. У компании есть офисы в Великобритании, ОАЭ, Португалии и на Кипре. В 2025 году она впервые привлекла $34 млн инвестиций по оценке $150 млн. Раунд возглавил сооснователь Veeam Software Ратмир Тимашев.
Мираи - страшный червь и одна из тойот. А Mirai AI - платформа для запуска и дообучения больших языковых моделей на гаджетах пользователей. Стартап запустили сооснователь нашумевшего в своё время фотосервиса Prisma Алексей Моисеенков и сооснователь приложения Reface Дмитрий Швец.
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
Теперь, когда Crunchy стала частью озёрной Snowflake, Пол Рэмзи (Paul Ramsey), папа PostGIS, пишет о PostGIS Day, им организованном уже под эгидой Снежинки. Соорганизатором была Элизабет Кристенсен (Elizabeth Christensen). Это 7-е по счёту мероприятие, прошедшее 20 ноября, изрядно переформатировали. Спикеров смогли пригласить "от Индии до Африки, от Европы до Северной Америки", чему радуется Пол.
И говорили они в основном об ИИ - что он может внести полезного в PostGIS. Немало. Пол говорит:
Переходя от общих восторгов вокруг ИИ к практической реальности агентов, мы увидели инструменты от Felt, Carto и Bunting Labs, которые действительно могут писать в базу, выполнять и отлаживать пространственный SQL на лету. Мы также увидели, что архитектура lakehouse заняла центральное место, а PostGIS выступает уже не как изолированное хранилище данных, а, скорее, как высокопроизводительный коннектор к обширному миру объектного хранения, Iceberg и GeoParquet через такие инструменты, как pg_lake и Apache Sedona. И это были действующие проекты. Мы увидели, что пространственные агенты - это не просто чат-боты, галлюцинирующие SQL. Мы увидели их в системах, рассчитанных на итерации запросов.
Полный плейлист выступлений на канале Snowflake.
Хорошо известный нам Дарафей Пролясковский (Darafei 'Котяра' Praliaskouski, Maumap) и Альпер Динсер (Alper Dincer) рассказали об использовании гексагонов. Дарафей показал, как создавать конвейеры в PostGIS и H3 для моделирования mesh-сети LoRa Mestastic дорог и административных границ. Альпер показал, как drought.uk - его платформа - использует H3 для агрегации огромных климатических наборов данных, превращая тяжелую обработку растров в быстрые SQL-запросы, поддержанные индексами.
У Брендана Эшворта (Brendan Ashworth, Bunting Labs) агент пишет запрос, разбирает сообщение об ошибке, если что-то пошло не так, исправляет его. Mundi - WebGIS с ИИ - решает сложные пространственные задачи без участия человека. У Хайме Санчеса и Мамата Акеллы (Jaime Sanchez, Mamata Akella, Felt) агенты прекрасно разбираются в расплывчатых понятиях "рядом" и "внутри".
У Райана Миллера (Ryan Miller, Carto) агент мог идентифицировать свободные земельные участки, фильтровать по экологическим ограничениям, а затем сохранять результаты обратно в базу данных Postgres.
Фавад Куреши (Fawad Qureshi, Snowflake) продемонстрировал, как размываются границы между транзакционными и аналитическими системами, как Snowflake и PostGIS могут обмениваться данными без копирования, позволяя тяжёлым аналитическим нагрузкам работать параллельно с операционными приложениями без конкуренции за ресурсы.
Building a RAG Server with PostgreSQL - Part 3: Deploying Your RAG API
И ещё раз напоминаем о почти что манифесте Дейва Пейджа:
я понял, что не хочу работать в компании, которая быстро становится ориентированной на искусственный интеллект. Я перешёл в pgEdge, где внимание и усилия сосредоточены на распределённом PostgreSQL.
Не то, чтобы он разорвал все отношения с ИИ. Теперь вот рассказывает, как соорудить RAG-сервер, уютно расположив его между приложением и LLM.
В Части 1 загрузили документацию в PostgreSQL. В Части 2 разбили эти документы на чанки и сгенерировали векторные эмбеддинги. А в этой, в Части 3, собирают всё вместе. Теперь есть простой HTTP API для вопросов, использующих собственную документацию вопрошающих.
pg_llm_helper 0.1.0 - Troubleshooting errors with OpenAI's gpt-4o-mini model
Автор расширения - Джёф Монти (Geoff Montee). Оно интегрирует модель gpt-4o-mini (OpenAI) прямо в PostgreSQL, что может помочь отслеживанию ошибок.
ПиДжи & ЭйАй от Савелия
Safreliy написал уже 14 статей на эту тему на Хабре. Мы следили с самого начала. Отрекомендовался Сафрелий-Савелий Батурин следующим образом: программист-математик (в Postgres Professional). Начнём в обратном хронологическом порядке:
Выбор LLM и фреймворка для ИИ-агентов
Статья технологичная и специализированная: много терминов и незнакомых (мне) аббревиатур.
Сначала Савелий перечисляет дюжину задач, которые ставили перед ИИ-командой. Вот, например, задача #4:
Graph-RAG-агент над большой кодовой базой на C (ИИ-Copilot). Ядро PostgreSQL и сопутствующие проекты - это миллионы строк C-кода. Мы строим граф знаний в Apache AGE: вершины - директории, файлы, функции, структуры, макросы, переменные; рёбра — вложенные зависимости и вызовы. Агент поверх этого графа отвечает на вопросы о том, где реализовано вот это поведение, чем чревато изменение такого-то участка и помогает с навигацией по коду как по базе знаний, а не как по сплошному тексту с поиском.
А вот #6:
Генератор hint-сетов для PostgreSQL. Здесь в центре всего расширение pg_hint_plan. Модель видит запрос, статистику, индексы и предлагает подсказки в формате hint-сетов. Обучаем это дело при помощи GRPO, параллельно зажимаем формат подсказок формальной грамматикой [да! см. ниже], чтобы pg_hint_plan мог их распарсить и применить.
По этому пункту есть разъяснение: hint-сеты: где дообучение действительно оправдано [так как 90% задач решается "из коробки"]:
Дообучение у нас оправдано в двух случаях:
когда нужна небольшая модель под конкретный сценарий, например, on-prem у клиента, где нет мощных GPU.
когда требуется очень специфичный формат вывода, который трудно стабильно выжать из модели одними промптами.
Ну и выборы: как пришли к текущему стеку: vLLM, Qwen3-Next-80B и свой агентный слой.
Пропустим статью Как мы обеспечили +33% к точности на сложных SQL-запросах, и немного задержимся на:
Будущее ИИ — формальные грамматики
Сильное утверждение. Человеческий язык - говорит Сафрелий - это механизм, который ограничивает бесконечную вариабельность возможных звуков и их последовательностей в строгую систему коммуникации.
Фонемы ограничивают сочетания звуков. В русском языке, например, их всего 42.
Слова ограничивают сочетания фонем и переводят наш мир в дискретное множество понятий — так рождается семантика.
Предложения, в свою очередь, ограничивают сочетания слов, создавая структуры для описания явлений воспринимаемого нами мира.
Все эти ограничения составляют суть языка, его синтаксис и семантику.
К нашему счастью, человеческий язык не такая уж строгая система. Но это постановки задачи не отменяет. Ох, просим прощения, дальше следует разъяснение автора:
Наш язык всё ещё остаётся излишне свободным и эту свободу большие языковые модели с лёгкостью перенимают.
Дальше - изрядная программистско-математическая заумь, которую мы здесь воспроизводить не будем: всё же Новый год на носу.
Вместо этого перенесёмся в самое начало писательской карьеры Сафрелия на хабре:
Нейронные оптимизаторы запросов в реляционных БД (Часть 3): Погружение в ранжирование
Нейронные оптимизаторы запросов в реляционных БД (Часть 2): На пути к продуктивизации
Нейронные оптимизаторы запросов в реляционных БД (Часть 1)
Разработчик - TensorChord (в Postgresso #2 за этот год есть даже портрет сооснователя этой компании, где замечены только сотрудники с китайскими фамилиями).
VectorChord совместим с типами данных и синтаксисом pgvector, но использует индекс IVF (Inverted File Index) и квантование RaBitQ для дополнительной производительности как при индексации, так и при поиске. Претендует на умение «хранить в 26 раз больше векторов, чем pgvector, за ту же цену».
Это наследник их же разработки pgvecto.rs. Теперь вот юбилейный VectorChord 1.0.0. А не так давно, в сентябре был ещё VectorChord 0.5.3. Документация здесь.
Introduction - PostgreSQL AI Query Extension (pg_ai_query)
Это расширение, которое принимает запросы на естественном языке, и на лету преобразует их в SQL, используя модели OpenAI либо Anthropic. Гитхаб здесь. Разработчик - Сачин Бенодивал (Sachin Beniwal, benodiwal) из Бангалора. В README много примеров.
Короче:
1-2-3-4-5, я [ИИ] иду искать. Кто не спрятался - я [ИИ] не виноват [?].
Ещё конференции
Не путать с PGConf.Russia, о которой ниже. PGPro TechDay фокусируется на произведениях Postgres Professional. Пройдёт уже 27 января в Москве в гостинице "Рэдиссон Славянская" на площади Евразии (бывшей площади Европы).
Кроме главного конференц-зала, который отдадут тематике Postgres Pro Enterprise 18.1.1, доклады пройдут в зале "Толстой" - его отдали аналитическим решениям:
Postgres Pro Axe: Аналитическая СУБД от Postgres Pro. Просто добавь OLAP - Андрей Кулага (Postgres Professional).
AXE это не только топор, но и Analitical aXElerator. Pgpro_axe - это расширение, работающее с Postgres Pro Enterprise. Оно оптимально для работы с большими и гибридными нагрузками без перехода на MPP. Область применения - OLTP и большие OLAP (а Tengri, о которой подробно расскажем уже в январе, - для работы с очень большими OLAP). AXE ориентирована на файлы parquet на S3 или локально.
Советую не забывать и о зале "Пушкин", где пройдут воркшопы. Например, по тому же AXE будет проводить воркшоп Денис Гидин (тоже, конечно, Postgres Professional): Postgres Pro AXE — колоночный векторный сверхбыстрый инструмент для аналитики.
Будут работать стенды с демонстрациями ключевых продуктов и сервисов Postgres Professional:
Postgres Pro Enterprise 18,
Shardman - распределенная реляционная СУБД,
ProGate - комплексное решение для миграции и репликации данных с автоматизацией ключевых этапов работы.
Ask Postgres - AI-ассистент для работы с базами данных,
Professional Services по внедрению, сопровождению и развитию решений.
Состоится 23 – 24 марта 2026 в World Trade Centr (Москва, Краснопресненская наб., 12, вход №4). Открыты регистрация, заявки на доклады и мастер-классы.
A Meetup Quiz? (Брюс о разных постгресовых ивентах)
Это постгресовая часть блога Брюса Момджана. Из короткой заметки мы узнаём, что Брюс за год поучаствовал в более 100 Postgres-ивентах. Остановиться поподробней он решил на Armenia PostgreSQL User Group meetup, который организовала Эмма Сароян (Emma Saroyan). Она очаровала Брюса оригинальностью замысла митапа: после его лекции она устроила мобильный квиз.
Ещё Брюс пишет "о недавней конференции в Риге" - то есть прошлогодней PGConf.eu. Но заходит с неожиданной стороны. Он решил остановиться на панельной дискуссии How to Work with Other Postgres People.
Другие - это да, те самые: люди с Mental Health issues.
Тема интересная, но я не читал описание, и содержание меня удивило. Выступавшие откровенно говорили о своих трудностях в общении с другими, и это побудило аудиторию тоже быть открытой и делиться впечатлениями. Для меня это было больше похоже на церковное молитвенное собрание, чем на доклад. Я сказал: такие доклады должны быть на каждой конференции.
Блог Брюса раздваивается на Postgres и Вообще. В порядке исключения заглянем и в Вообще - чем ещё интересуются Postgres-классики?
Ого! Suicide and Responsibility - самоубийство и ответственность:
Брюс прочитал статью в Atlantic о легализации в Канаде медпомощи в умирании (medical assistance in dying - MAID) и пишет по этому поводу:
Но существует другая версия либерализма [кроме той, где жизнь полная собственность живущего - "что хочу, то с ней и делаю" - поэтому, по этой версии, мешать самоубийству - преступление]. Назовём это либерализмом, основанным на дарах. Он начинается с иной базы: я - получатель даров. Я получил множество даров от тех, кто был до меня, включая сам дар жизни. Суть жизни - не в стремлении к индивидуальному счастью. Суть жизни - в реализации даров, которые мне дали мои предки, и в передаче их, должным образом улучшенных, тем, кто придёт после.
Хм, как-то не новогодне получилось. Но смысл-то жизнеутверждающий! Пусть останется - в уходящем году.
What Postgres developers can expect from PGConf.dev
Это Мелани Плейгман (Melanie Plageman) делится своими ожиданиями в подкасте Talking Postgres with Claire Giordano. PGConf.dev 2026 пройдёт 19-22 мая в Ванкувере в кампусе Университета Саймона Фрейзера. Приём заявок на доклады действует до 16 января.
Перенесёмся опять в прошлое, чтобы насладиться
Postgres Trip Summary from PGConf EU 2025 (with lots of photos)
Отчёт Клэр Джордано (Claire Giordano) на Microsoft Community Hub. Всё так и есть: очень много фотографий!
На этом на сегодня всё. Точнее: всё в 2025. Встретимся в 2026. С НАСТУПАЮЩИМ!