Да что ж это делается? Хрустящие данные обратились снежинками, новый кирпичик данных стал неоновым, временная шкала обратилась в тигра и Xata переродилась
Два события заставили нас начать этот выпуск не с новостей о релизе. Snowflake купила Crunchy Data, а Data Bricks приобрела Neon. Что важнее, что сенсационней? Crunchy Data - компания-ветеран, Neon - стартап. Рыночная стоимость, однако, оказалась у стартапа в 4 раза больше. А тут и ещё 2 события (не столь сенсационных конечно). Но начнём с ветеранов.
Crunchy
Первая же фраза новости говорит: приобрели, чтобы интегрировать в AI Data Cloud. Компания возникла 13 лет назад в 2012, когда все говорили о NoSQL. Упрямство победило, Postgres и вообще реляционные СУБД живы, здоровы и полны планов на будущее.
Crunchy Data одна из первых сделала свой оператор Kubernetes - это, видимо, и привлекло внимание Snowflake. Crunchy Bridge - Postgres DBaaS, работает из коробки. Компания опять же одной из первых сделала интеграцию Postgres с Apache Iseberg - навстречу клиентам, нацеленным на аналитические нагрузки.
В 2015 к Crunchy присоединился Том Лейн (Tom Lane) - а он один пишет столько строк кода, сколько и компания среднего размера не напишет. Он входит в Postgres Core Team. Другой важнейший для сообщества человек - канадец Пол Рэмзи (Paul Ramsey). Без него PostGIS не был бы PostGIS; он поддерживает и другие приложения, входит в список Major Contributors. В список контрибьюторов (без major) входит Грег Сабино Маллейн (Greg Sabino Mullane), последнее время его броское имя мелькало довольно часто на конференциях и в наших обзорах. Стивена Фроста (Stephen Frost) не помню, но он тоже официальный контрибьютор.
Может, кто помнит, что был такой любопытный сюжет, о котором мы писали в Postgresso #1 (74):
Разжалование: DB-Engines уже анонсировала: Postgres стал СУБД 2024, и — нате: СУБД года по последним новостям вовсе не Postgres, а Snowflake. У меня даже сохранилась в черновике ссылка с названием PostgreSQL is the Database Management System of the Year 2024, ведущая туда же, куда теперь ведёт Snowflake is the Database Management System of the Year 2024. До того это звание Postgres присуждалось в 2017, 2018, 2020 и 2023 годах.
Заметьте: не облачная компания, а именно СУБД. Но уже в Postgresso #5 (66) мы писали:
А вот что делается в мире Snowflake - одной из самых быстроразвивающихся СУБД с идеологией ... эээ ... которая всё больше размывается. В 2020 директор Снежинки Фрэнк Слутман (Frank Slootman) признался: мы хотели создать облачную РСУБД - WH с вертикальным хранением, чтобы данные хорошо обрабатывались в архитектуре MPP, но получилось нечто большее. Ну а сейчас в их релизах и блогах днём с огнём не найдёшь упоминания SQL - всё данные-данные-данные.
И вот теперь Снежинки прибирают к рукам Хрустящие Данные, чтобы покорять мир своим Snowflake Postgres. Источники, например, в новости Snowflake's Strategic Acquisition: Crunchy Data Joins the AI Data Cloud на parsers.vc называют сумму $250 тыс.
Neon
Neon, хоть и молоденькая компания (г.р.2021), но и там есть основные (major) контрибьюторы - это сооснователь компании финн Хейки Линнакангас (Heikki Linnakangas) и Анастасия Лубенникова (Anastasia Lubennikova). Вообще многих из Neon мы хорошо знаем - это очень квалифицированные разработчики и симпатичные люди, многие из них физики с бэкграундом МИФИ. Успеха им!
Вот такое название у анонса на Databricks. Самое интересное в этом сообщении то, что клиенты Неона в основном не человеки: после опубликования общедоступной версии команда NeonDB обнаружила, что 30% баз создали ИИ-агенты, а не люди. А незадолго до покупки люди Databricks глянули в статистику Neon, и оказалось, что уже 80% баз создали нечеловеки.
Databricks в этой тематике с самого начала. Соучредитель Databricks Энди Конвински (Andy Konwinski) ещё и сооснователь ИИ-поисковика Perplexity AI, что не мешало ему, конечно, вместе с другими сооснователями Databricks создать в своё время Apache Spark. А если пробежать по диагонали (950 докладчиков!) список выступающих на их Data + AI Summit, прошедшем 9-12 июня, то там выступает лично гендир и сооснователь Anthropic Дарио Амадей (Dario Amodei). Кстати, там ещё и председатель совета директоров и гендир Microsoft Сатья Наделла (Satya Nadella) и председатель совета директоров и гендир JPMorgan Chase Джейми Даймон (Jamie Dimon).
Из трёх основателей Neon - Никиты Шамгунова, Хейкки Линнакангаса и Стаса Кельвича (Nikita Shamgunov, Heikki Linnakangas, Stas Kelvich) - Никита не был до Neon связан с Postgres. Зато он начинал как бронзовый призёр Международной студенческой олимпиады по программированию - ACM ICPC. Потом работал над оптимизацией SQL Server и инфраструктурой для обработки огромных массивов данных, а в 2011 основал MemSQL (SingleStore) и дорастил компанию до оценки в $1,3 млрд при $238 млн инвестиций. После этого Никита стал партнёром в Khosla Ventures (это мы знаем в том числе от Мыслей вслух).
Neon and Databricks. A new chapter - так об этом написали на Neon.
В российской деловой прессе к этим покупкам отнеслись довольно спокойно. В крохотной заметке на Ленте сказано:
Snowflake, компания по облачному хранилищу данных, и Databricks, фирма по аналитике данных, бьются голова к голове, преследуя компании, которые хотят создавать искусственных интеллектуальных агентов и другие приложения на основе собственных данных.
Snowfklake и Databricks разные, Neon и Crunchy Data совсем разные, но с формулировкой бьются голова к голове можно, пожалуй, согласиться. РБК об этих сделках не стала оповещать, хотя о Databricks писала не раз: мол, пионер и лидер озёр данных, да ещё и свою открытую LLM создаёт. И вообще: Лидеры рынка слияний и поглощений на данный момент — Nvidia, Snowflake, Accenture, Databricks. Неплохая компания (в обоих смыслах).
По версии "большого" Форбса, кстати, Databricks - 3-я по рыночной стоимости в топ-100 облачных компаний.
Xata
Компанию Xata никто пока не покупал и не продавал, но её метаморфозы вписываются, нам кажется, в этот ряд с Neon-Databricks и Crunchy-Snowflake. Она вела себя на рынке весьма активно, её сотрудники участвовали в конференциях, писали статьи нам на радость, переходили в Xata из других компаний. Вот, например, энергичная Гюльчин Йылдырым Джелинэк (Gulcin Yildirim Jelinek), часто появляющейся в наших обзорах (она у нас тогда была Гюльчин Ильдирим Йелинек - с тех пор мы чуть-чуть узнали о турецком языке). Ещё в 2024 Гюльчин работала в EDB, а в январе этого года уже писала в блоге в статусе сотрудницы Xata, например: Anatomy of Table-Level Locks in PostgreSQL (о ней в нашем разделе Ещё статьи).
Теперь мы узнаём, что Xata решила начать всё с нуля, объявила о новой стратегии и новой архитектуре. У них теперь развитая среда для того, чтобы:
плодить версии базы на основе Copy-on-Write, но не как у postgres.ai;
развивать разделение вычислений и хранения, но не как у Neon.
И вообще у них там немало интересного и необычного.
Postgres with data branching and PII anonymization
Подзаголовок у статьи - Relaunching Xata as "Postgres at scale". A Postgres platform with Copy-on-Write branching, data masking, and separation of storage from compute, а автор - техдир компании - Тудор Голубенко (Tudor Golubenco, работал в Elastic Beats главным разработчиком, живёт в Берлине). Так что это вполне концептуальная статья. В названии статьи PII = personally identifiable information - персональные данные. Но больше говорится об at scale - о масштабируемости, которую в Xata понимают очень широко: это не просто бери больше кидай дальше (объёмы, сервера в штуках и т п), а ещё и:
Нулевое время простоя (Zero-downtime) при изменении схемы и миграции на другую мажорную версию.
Тестирование изменений в базе или в обучаемых ИИ-моделях на реалистичных наборах данных, которые похожи на промышленные, но без реальных персональных данных или другой конфиденциальной информации.
Быстрая, эффективная по цене/качеству тестовая (ephemeral) среда специально для разработчиков.
Соответствие законодательным требованиям для работы с чувствительными данными.
Вот для этого, говорит Тудор, и служат:
Мгновенное создание ветвей данных Copy-on-Write.
Данные сразу анонимизируются.
Всё работает для любых облаков AWS/GCP/Azure или у себя.
Хранение и вычисление разделены так, что доступ к распределённой системе хранения идёт через NVMe/TCP. Изменения все в ней (используется Simplyblock партнёров), а PostgreSQL запускается без патчей.
Хорошее отношение цена/качество при больших масштабах.
После того, как наплодили и протестировали множество версий с изменёнными схемами данных, можно их безопасно слить с основной рабочей базой.
Не всё с нуля, конечно. Из "старой жизни" в новую они взяли:
pgstream - репликация с DDL-изменениями, только теперь с маскированием/анонимизацией;
pgroll - изменения схемы без простоя.
И, конечно, вовсю задействован Kubernetes.
Timescale
Как эти попали в компанию претерпевших радикальные изменения? У этих по сути не поменялось ничего: всего лишь ребрендинг Timescale => Tiger Data. Но ребрендинг-то концептуальный: временные ряды ушли в тень, зато данные в свете маркетинговых прожекторов. Причина ребрендинга понятна: timescale звучит узковато по нынешним временам. И база - узковато, и расширение - тем более узковато. А данные - норм: туда и AI с векторным поиском, и индексы DiskANN и HNSW к ним - всё можно подверстать. И поговорить об облаках, конечно.
А тигр неспроста появился: не так давно инвестиционный раунд на $110 возглавлял фонд Tiger Global. В результате рыночная стоимость (оценка - evaluation) Timescale перевалила за $1 млрд.
PostgreSQL 18 Beta 1
Выход беты - событие не такое торжественное, как выход официального релиза, зато более интересное. Когда выходит релиз-кандидат, а тем более официальный релиз, все уже давно обсудили и расписали новшества релиза. А бета - самое время для знакомства с PostgreSQL 18. Скачивать бету здесь. А вот - заметки к релизу - release notes.
На этот раз - для разнообразия - мы будем перемежать краткие описания новых фич появившимися статьями о них. И, конечно, напоминаем, что мощнейший источник по теме - это статьи-обзоры Павла Лузанова - PostgreSQL 18: Часть 4 или Коммитфест 2025-01 и предыдущие серии: 2024-11, 2024-09 и 2024-07.
Коллективный разум сообщества из нововведений выделяет прежде всего новую - асинхронную - систему ввода-вывода. На Linux можно использовать io_uring в ядре, но вообще создали механизм на постгресовых фоновых процессах (background workers), работающих на всех платформах. Сейчас можно работать асинхронно, например, при последовательном сканировании (sequential scans), сканировании битовых карт (bitmap heap scans), и вакууме. Выигрыш в скорости доходит до 2-3 раз. Но это начало. Разработки продолжаются.
Сразу сошлёмся на некоторые статьи, рассказывающие подробности.
Waiting for Postgres 18: Accelerating Disk Reads with Asynchronous I/O
Лукас Фиттл (Lukas Fittl, pganalyze) рисует внятные диаграммы, рассказывает предысторию в PostgreSQL 17 и перспективы в PostgreSQL 19+. Вообще-то, сейчас это не асинхронный ввод-вывод. Читать асинхронно научились, а вот писать научатся в будущем. Лукас показывает, как настраивать, как мониторить и как тестировать.
Но и российские ресурсы пишут о вводе-выводе:
PostgreSQL делает ставку на IO_uring — и не зря
Точнее, это предвкушали на сайте SecurityLab (Positive Technologies) задолго до выхода 18-й.
Вторая группа изменений - улучшения по части индексов. Выиграют многоколоночные B-tree, предложения WHERE, содержащие IN или OR, а несколько OR планировщик научился заменять на конструкцию с ANY; распараллелили создание индексов GIN, важнейших для поиска по JSON и полнотекстовым данным. Кстати, ускорили и функции upper/lower и новые правила сортировкиPG_UNICODE_FAST.
Универсальные уникальные идентификаторы UUIDv7 для индексирования тоже вещь важная:
Гвин Шапира (Gwen Shapira, Nile) разбирает несовершенства предыдущих версий UUID и радуется поддержке UUIDv7 в PostgreSQL 18. Версия 7 UUID основана на временной метке (timestamp-based). Хорошо работает с индексами типа btree. В статье говорится и об UUID вообще, и об особенностях v7, и что получат пользователи PostgreSQL.
Появились виртуальные генерируемые столбцы - они вычисляются прямо во время исполнения запроса, а не хранятся. Более того, так теперь происходит по умолчанию. Зато те сгенерированные столбцы, которые хранятся, теперь можно логически реплицировать.
Об этом даже уже успела появиться заметка на хабре Антона Околелова @varanio: Virtual generated columns в PostgreSQL 18. На эту тему также есть статья Дэниэла Вестерманна (Daniel Westermann, DBI Services) на dbi Blog: PostgreSQL 18: Virtual generated columns.
Ещё интересное:
При обновлении на новую мажорную версию планировщик теперь сохраняет накопленную статистику. А сама утилита pg_upgrade может проводить проверки параллельно другим действиям - в зависимости от заданных флагов.
В предложениях RETURNING для INSERT, UPDATE, DELETE и MERGE теперь можно обращаться к предыдущим (OLD) и текущим (NEW) величинам.
Новое появилось в работе с LIKE; сPRIMARY KEY и UNIQUE, использующими WITHOUT OVERLAPS и в ограничениях FOREIGN KEY, использующими PERIOD.
По безопасности авторы релизных заметок и авторы статей выделяют новый метод аутентификации oauth, который использует механизмы OAuth 2.0, который поддерживается расширениями.
В мониторинге сильно обогатился EXPLAIN , это как раз подробно разобрано в каждом (!) из обзоров Павла Лузанова (ещё раз ссылки: 2025-01, 2024-11, 2024-09 и 2024-07).
Ещё интересное новое, которое не часто попадает в обзоры о новом в PostgreSQL 18: новая версия (3.2) протокола PostgreSQL. Это маленькая революция: протокол не обновлялся с версии PostgreSQL 7.4 в 2003 (libpq по-прежнему использует по умолчанию версию 3.0).
Подробности в заметках к выпуску (они же release notes).
Официальный релиз должен появиться в сентябре/октябре, перед этим будут ещё беты (сколько понадобится) и релизы кандидаты (сколько понадобится). Вот страница для бета-тестировщиков. Другие полезные страницы:
В заключение вот пара статей, где разбираются не отдельные новые фичи, а примерно всё самое важное (для авторов) в бете.
What's New in PostgreSQL 18 - a DBA's Perspective
Действительно, автор Тяньджоу (Tianzhou, Bytebase) в каждом пункте выделяет ценное/удобное именно для админа. Например:
Ограничения NOT NULL как NOT VALID.
Это позволяет пользователям добавлять ограничения NOT NULL без сканирования сразу всей таблицы, а уже позже делать проверку, не удерживая блокировку ACCESS EXCLUSIVE. <...>
Для админа базы:
Это настоящее сокровище (godsend - даже дар свыше) для тех из нас, кто управляет большими рабочими базами данных, где простои измеряются долларами в секунду. Больше не нужно планировать окна технического обслуживания в 3 часа ночи ради добавления ограничения NOT NULL к таблице объемом 10 ТБ. База не даёт появляться новым значениям NULL, помечая ограничение как (пока) недействительное - это идеальный баланс: целостность данных без боли немедленной проверки.
Или:
Виртуальные генерируемые столбцы (Virtual generated columns):
PostgreSQL 18 меняет подход к обработке генерируемых столбцов, теперь генерируемые столбцы виртуальны по умолчанию. Из заметок к выпуску мы знаем, что значения этих столбцов вычисляются как compute-on-read. <...>.
Для админа базы:
Это может заметно сэкономить место на диске и уменьшить издержки записи для столбцов, которые вычисляются на основе других, и не требуют физического хранения. Представьте себе все эти сконкатенированные полные имена. Или простые вычисления. Разумеется, компромисс заключается в вычислении при чтении. Но, соответственно, запросы к этим виртуальным столбцам могут столкнуться с небольшим снижением производительности, особенно если логика генерации сложная.
Postgres 18 Beta Is Out: 7 Features You Should Know About
О новом в бете решил рассказать и сооснователь Neon Хейкки Линнакангас. Это не анализ фич, а, скорее, (ведь тоже полезный) жанр "выбор Хейкки". И начинает он с асинхронного ввода-вывода:
новая асинхронная система ввода-вывода даёт возможность параллельно исполнять запросы на чтение и продолжать исполнение, ожидая результаты. Теперь есть 3 метода ввода-вывода, иногда дающих ускорение до 2-3 раз:
sync - традиционное поведение - синхронное и блокирующее.
worker - новый метод, включается по умолчанию.
io_uring - использует разделяемые кольцевые буферы (shared ring buffers) ядра Linux.
EXPLAIN ANALYZE теперь показывает новые детали runtime:
По умолчанию показывает буферы и ввод-вывод.
Узлы Index scan nodes теперь делятся информацией о том, сколько раз заглянули в индекс.
В режиме VERBOSE показывает, сколько было записей WAL, время CPU и среднее время чтения.
В представлении pg_stat_all_tables появилась статистика вакуума (и total_vacuum_time, total_autovacuum_time) и ANALYZE.
Новая функция
uuidv7()генерит UUID-ы, которые можно отсортировать по TIMESTAMP.Строить GIN-индексы можно теперь параллельно.
Новая возможность
skip scanработает в индексах btree.Новый метод идентификации oauth.
Кому надоели беты, - вот альфа. Эта версия лучше всего работает с (Best Served with - как любят говорить ПостГИСисты) с PostgreSQL 18 бета1, GEOS 3.13.1 (с GEOS 3.12+), Proj 6.1+ и SFCGAL 2.1.0+ (чтобы работали все его фичи). Но, если надо, будет работать с версиями PostgreSQL 12+, GEOS 3.8+. Ссылки:
NEWS - я насчитал 11 новшеств; появились 2 несовместимости с предыдущими версиями (breaking changes);
Шпаргалки:
Ну и заодно PostGIS 3.5.3:
В этой версии пофиксили баги.
PostgreSQL 17.5, 16.9, 15.13, 14.18 и 13.21
Причина их выхода - проблема безопасности CVE-2025-4207 + около 60 исправленных багов, накопившихся за несколько месяцев.
При валидации кодировки GB18030 могло произойти переполнение буфера, что могло дать возможность чтения данных на 1 байт за пределами буфера. На некоторых платформах это могло привести к завершению процесса и временному прекращению работы сервера или библиотеки libpq. Читайте release notes.
Ветвь PostgreSQL 13 больше не будет поддерживаться с 13 ноября этого года, 2025, исправления не будут вноситься. Подробнее в политике поддержки версий.
Postgres Pro Enterprise:
13.21.1: репозиторий пакетов, документация, описание релиза
14.18.1: репозиторий пакетов, документация, описание релиза
15.13.1: репозиторий пакетов, документация, описание релиза
16.9.1: репозиторий пакетов, документация, описание релиза
17.5.1: репозиторий пакетов, документация, описание релиза
Но это не всё:
На этой странице когда-то были 3 колонки: PostgreSQL, Postgrs Pro Standard, Postgres Pro Enterprise. Население этой страницы заметно возросло - добавились (я развернул ветки):
ora2pgpro:
shardman
Postgres Pro OpenTelemetry Collector:
Postgres Pro Backup Enterprise 3:
Postgres Pro Enterprise Manager:
Подробней, допустим, о последнем (ок, крайнем) пункте:
Изменения в версии 2.1 (здесь - только разделы):
Работа с кластерами репликации и интеграция с менеджером отказоустойчивости BiHA.
Управление источниками данных.
Пользовательские SQL-метрики.
Обновление панели навигации.
Проверка целостности каталога данных экземпляра.
Добавление роли "Пользователь консоли".
Установка и работа с расширениями.
Установочные пакеты доступны в репозитории. PPEM поддерживает установку и работу на следующих дистрибутивах Linux:
ALT Linux СП 10, ALT Linux 10, ALT Linux 11, Astra Smolensk 1.7, Astra Smolensk 1.8, Debian 11, Debian 12, RedOS 7.3, RedOS 8.2, RHEL 8, RHEL 9, ROSA 2021.1, Suse Linux Enterprise Server 15, Ubuntu 20.04, Ubuntu 22.04, Ubuntu 24.04.
Теория
Decomposing Transactional Systems
Статья в блоге Алекса Миллера (Alex Miller), но информация восходит к целой команде авторов: Irene Zhang, Naveen Kr. Sharma, Adriana Szekeres, Arvind Krishnamurthy и Dan R. K. Ports. Они раскладывают по полочкам транзакции. Каждая транзакция, между прочим, состоит из 4 действий:
исполнение транзакции (execute),
упорядочение транзакции (order),
проверка транзакции (validate),
закрепление транзакции (persists).
Пояснив "что к чему", авторы рассматривают примеры, иллюстрирующие разные подходы к этим действиям, которые отнюдь не обязательно происходят последовательно. Примеры там не столько конкретных СУБД, сколько транзакционных протоколов. Они не все самые мейнстримные. Это:
Spanner (Google).
TAPIR - создатели говорят, что это улучшенный Spanner.
CURP (Consistent Unordered Replication Protocol).
TicToc (это протокол)
Далее прилагается список СУБД для домашнего задания: все они, утверждает автор, работают с этой четвёркой действий по-разному, а вы, дорогие студенты, разберитесь, каким образом.
А вот в этих компаниях задание уже выполнили и сами всё объяснили:
Железо
Modern Hardware for Future Databases
Редкая тема. Речь не о том, как приспособить под PostgreSQL сервера помощнее. А о том, как поручить специализированному железу (GPU, TPU, FPGA) ресурсоёмкие вычисления. Что тут в принципе можно сделать, а что нельзя. А вдохновила на эти рассуждения статья OLTP Through the Looking Glass, and What We Found There - статья не новая (появилась, говорят, в связи с SIGMOD 2008), но там в среди авторов папа PostgreSQL - Майкл Стоунбрейкер. Здесь есть её пересказ.
Начали попытки сэкономить со стека TCP/IP - он отжирает 60% процессора на детище Майкла VoltDB. Рассматривают разные варианты, все не особенно эффективные. Вроде, должен помочь RDMA.
По части хранения смотрят на разные технологии последнего времени - NVMe SSD, SmartSSD и другие.
В контексте обработки транзакций говорят о unikernel-ах - специализированных ОС для баз данных, упрощающих управление памятью и вводом-выводом; также о важности синхронизации часов.
FPGA и ASIC не особенно спасают из-за узких мест в пропускной способности памяти.
Ну? Какие же стандартные операции перепоручить железу? Я так понял, что наиболее перспективно и реалистично - это поручить железу (Smart NIC - smart network interface card, например) заниматься проверкой чексумм и разбираться с сегментацией. Но тема огромная и очень интересная, может я что-то недопонял. Можно почитать на тему и здесь: Segmentation Offloads — The Linux Kernel documentation.
Наследие
New PostgreSQL support in IBM COBOL for Linux on x86
Не уверен, что хотя бы одному нашему читателю это пригодится на практике, но в этих IBM-овских анонсах дышит ИСТОРИЯ. В анонсе на PostgreSQL.org говорится о том, что интеграция PostgreSQL с COBOL реализована через сопроцессор, а не препроцессор: компилятор преобразует операторы EXEC SQL в операторы COBOL непосредственно во время процесса компиляции, а не на отдельном этапе до начала компиляции.
Сопроцессор COBOL для Linux с поддержкой PostgreSQL основан на препроцессоре PostgreSQL ECPG, адаптированном для работы с языком COBOL вместо языка C.
Statement of direction: IBM COBOL for Linux on x86 to include PostgreSQL support - Здесь больше подробностей и загадочных COBOLиcтических аббревиатурах, хотя о самом событии говорится ещё в будущем времени.
Советуют также почитать Programming for a PostgreSQL environment - для лучшего понимания интеграции.
Multigres под ручку с OrioleDB
Announcing Multigres: Vitess for Postgres
Supabase наняла специалиста со сложной фамилией - Сугу Сугуморане (и мы не уверены, что произносим её правильно - Sugu Sougoumarane), чтобы он развивал направление Vitess for Postgres - Multigres. Сугу - сооснователь и технический директор PlanetScale, он - один из создателей Vitess, занимался ею, когда работал в Youtube. С MySQL всё прекрасно работало, можно почитать здесь: Vitess: Scaling MySQL with Sugu Sougoumarane. Теперь вот Postgres.
Это стратегическое решение - статью эту написал Пол Копплстоун (Paul Copplestone) - сооснователь и гендир Supabase.
Multigres это продвинутый прокси, должен помочь работать со всей экосистемой Postgres. Пол подчеркнул, что недавно приобретённая OrioleDB будет дополнять Multigres.
Александр Коротков (Alexander Korotkov), создатель OrioleDB, написал, кстати, статью:
Why PostgreSQL needs a better API for alternative table engines?
Как всегда, там много важного и интересного, высокотехнологичного. А потом и ещё одну, не менее интересную, в жанре "но не как у XYZ", о котором было выше: The differences between OrioleDB and Neon.
Образование
С 1 июля по 1 августа 2025 года компания Postgres Professional проводит Летнюю школу для студентов, интересующихся разработкой системных решений и архитектурой СУБД PostgreSQL. С этого года студенты со всей России.
Обучение пройдет очно в офисе компании в новосибирском Академгородке. В первые две недели участники прослушают курс лекций об аспектах внутреннего устройства PostgreSQL, системном программировании, архитектуре операционных систем, обеспечении отказоустойчивости, высокой доступности и др. Со второй недели начнётся работа над практическими задачами по одному из треков: общесистемное программирование, производительность, машинное обучение (ML), тестирование (QA).
Конференции
Открыта регистрация и приём заявок на доклады и мастер-классы. Конференция состоится 29 сентября в гостинице Санкт-Петербург, Пироговская набережная, д. 5/2. До 15 августа режим early bird: участие со скидкой в 20%.
Это крупная конференция: планируется более 600 участников офф- и онлайн, более 15 докладов, 5 демонстраций и 5 мастер-классов. Будет и сертификация, но на неё запись отдельная.
Только что завершилась - проходила 23-24 июня. Вот её расписание. Посмотреть его имеет смысл: там выложены презентации. Вообще организаторы публикуют и ведео докладов. Докладов очень много - одних потоков аж 7 штук (считая "нетворкошную"). Вот некоторые доклады.
Собственное файловое хранилище для 350 Пбайт видеоконтента - Эдгар Воскресенский (где ж ещё могут быть такие масштабы? Конечно, это RUTUBE).
И более 400 млн единиц видеоконтента. Очень много слайдов, детали архитектурных решений, цифры. Архитектура хранилища была заложена еще до появления таких решений, как Ceph и Amazon S3, поэтому у нас всё своё - говорит Эдгар.
Пределы масштабирования дисковой СУБД Сокол - Андрей Коротченко, РЕЛЭКС.
РЕЛЭКС, Сокол - звучит как легенда. На популярных конференциях представители появляются не слишком часто.
Геораспределенное резервирование Postgres при помощи Debezium - Николай Голубев, HFLabs
Синхронизация данных между географически распределенными узлами БД Postgres с помощью Debezium и Kafka. Также о том, как автоматизировать переключение между базами в случае отказа и минимизировать простой.
Аналитика на больших графах в S3: инструменты, подходы и форматы для OLTP и OLAP - Алексей Теплов, Т-Банк, Алексей занимался и исследованием эффективности распределенных вычислений в НИВЦ МГУ.
Алексей рассказывает про графы с ~1 млрд вершин, ~50 млрд ребер с историей изменений. Всё в облачной инфраструктуре. JanusGraph поверх Cassandra, DuckDB с расширением DuckPGQ и GraphScope. Сами графы в S3. Сравнение форматов хранения LPG: от Parguet и Iceberg до нового GraphAR от Alibaba, с обсуждением их преимуществ и ограничений в сценариях OLAP и OLTP.
Ну и как без ИИ и LLM. Несколько докладов. Например:
Архитектура высоконагруженных RAG-систем: 10 стратегий оптимизации чанкинга и интеграция с Weaviate, Qwen / Llama / Gemma - Андрей Носов, Raft.
Ключевые стратегии чанкинга: интеграция Weaviate как векторной БД с поддержкой мультимодальности и гибридного поиска; оптимизация пайплайнов через LangChain и LlamaIndex для работы с Qwen и Llama; кэширование чанков и эмбеддингов в Redis для снижения задержек.
Кто написал код? Об авторских правах на код, написанный с помощью AI - Ирина Шахтарина, Сбер.
Доклад по материалам лицензионных соглашений ChatGPT, GigaChat, Copilot, Codeium, CodeWhisperer, Gemini. Ирина советует с ними не шутить.
Перемещаемся в более отдалённое прошлое. Вот от этой конференции в прошлый раз было столько кругов по воде, что в сумме целое цунами. Говорят, дальше - больше, но посмотрим. Пока что:
pgconf.dev 2025 Wraps Up with Great Success in Montreal
Одно время мы довольно часто обозревали статьи Кэри Хуана (Cary Huang), старшего разработчика в канадском отделении китайской компании HighGo. Продолжим эту традицию, только теперь Cary is a Senior Software Developer at Hornetlabs Technology (канадской компании с сильным Китайским уклоном, впрочем, в контактах - адрес @highgo.ca - ну да ладно).
Он как раз говорит, что pgconf.dev 2025 в Монреале ещё круче, чем прошлогодняя в Ванкувере: микс глубокого технологического контента (40 докладов) и общения с коллегами по комьюнити (в т.ч. бег - the Social Run, конечно).
Интересный список спонсоров. Среди них:
HUAWEI - среди золотых спонсоров,
Highgo Software (!) и NEON (!) - серебряных,
Очередное новшество придумал Андрей Бородин (Andrew Borodin, Яндекс). Вообще Андрей большой выдумщик - это он придумал в прошлом году Postgres Pre-Commitfest Party. На этот раз - Poster Session - вывешенные доклады на листочках формата А2.
Ещё Кэри понравился Стенд сообщества. Опять там заряжал энергией Бородин, Кэри даже написал: Bravo, Andrew!
Два доклада были по теме потоки vs. процессы:
Investigating Multithreaded PostgreSQL – Томас Мунро (Thomas Munro) и
Multithreaded PostgreSQL (2025 edition) – Питер Айзентраут (Peter Eisentraut).
Произведения OpenAI не обделили вниманием. Был доклад с таким вот странным названием:
ChatGPT Ain’t Got $%@& On Me! Next Generation Automated Database Tuning - Уильям Жань (William Zhang, Университет Карнеги Меллон) и был
Scaling Postgres to the next level at OpenAI - Боан - тоже Жань (Bohan Zhang, OpenAI).
Упомяну вслед за Кэри ещё 3 доклада:
What went wrong with AIO - Андрес Фройнд (Andres Freund),
What can Postgres learn from DuckDB? – Йелте Феннема-Нио (Jelte Fennema-Nio) - опять эти вездесущие утки!
Rethinking PostgreSQL Performance in the Age of Monster Hardware - Летиция Авро (Lætitia Avrot) - там в основном о NUMA, а эта тема меня не отпускает. Летиция говорит в том числе и о том, как с нумой справляются соседи и мы:
Oracle: память и процессы пользуются особенностями NUMA (NUMA-aware),
SQL Server: soft NUMA,
DB2: полная поддержка NUMA,
MariaDB и PostgreSQL: никакой поддержки.
Кроме того Кэри объявил (сославшись на выступление его коллеги Гранта Чжоу - Grant Zhou) новую постгресовую конференцию:
Она состоится в Китае, в городе Цзинян (Jinan), провинция Шаньдун. Уже завтра: 27-28 июня.
Состоится в Лондоне 9 сентября. До 31 июля действует режим ранних пташек (всего 20 билетов, они на 20 фунтов дешевле обычных 140-фунтовых). Заявки на доклады уже НЕ принимаются.
Логистику и другие сервисы обеспечит на некоммерческой основе Slonik Enterprises Ltd.
Конференция намечена на 29 сентября - 1 октября. Заявки на доклады уже не принимаются, но расписание пока недоступно.
PostgreSQL Conference Europe 2025
Из Афин конференция переместится в Ригу, где она пройдёт 21-24 октября. Но уже открыта регистрация, доклады принимаются (до 30 июня) - об этом сообщает Магнус Хагандер Magnus Hagander. А Андреас Шербаум (Andreas Scherbaum) предлагал до 10 июня придумать какие-нибудь Community Events & Activities из списка или собственные. Что из этого получилось, узнаем из расписания, когда появится.
Ещё статьи
Anatomy of Table-Level Locks in PostgreSQL
Гюльчин Йылдырым Джелинэк (Gulcin Yildirim Jelinek) пишет:
блокировки, которые находятся впереди в очереди, могут блокировать последующие блокировки, что приводит к каскадным задержкам. Рассмотрим пример:
Длительный запрос SELECT удерживает блокировку ACCESS SHARE LOCK.
Команда ALTER TABLE DETACH PARTITION требует кратковременную блокировку ACCESS EXCLUSIVE LOCK.
Поскольку эти блокировки конфликтуют, операция ALTER TABLE помещается в очередь блокировок.
Еще 20 бэкендов пытаются выполнить простые запросы SELECT для поиска по первичному ключу.
Эти запросы также конфликтуют с блокировкой ALTER TABLE, поэтому они ставятся в очередь за операцией ALTER TABLE.
В результате весь доступ к данной таблице теперь находится в очереди, и никакой обработки запроса не происходит до тех пор, пока не завершатся и длительный SELECT, и операция ALTER TABLE.
PostgreSQL and Ducks: The Perfect Analytical Pairing
В MotherDuck-блоге пишут о идеальных парах-аналитиках - Утке и PostgreSQL. Но, как выясняется, пары эти не то, чтобы равноправные. Один из двух оказывается подкаблучником. Но, вроде, ко взаимной выгоде. Возможны такие варианты:
DuckDB Postgres Extension: Уткобаза на локальной машине или в Мамеутке соединяется с базой PostgreSQL и вытаскивает из неё данные для анализа, как бы удалённо сканирует PostgreSQL.
pg_duckdb: в PostgreSQL устанавливется это расширение, и тогда Уткобаза действует внутри серверного процесса PostgreSQL - можно исполнять утиные запросы, а можно и получать данные из Мамыутки или других источников.
Supabase’s etl (fka pg_replicate) (CDC - Change Data Capture): формируется конвейер данных, дублирующий изменения в PostgreSQL в Мамыутки или другие системы почти в реальном времени. Используется логическое декодирование в PostgreSQL.
Для каждого случая рассматриваются компромиссы, плюсы/минусы.
Пока всё.