PostgreSQL: от исследовательского прототипа до стандарта экосистемы баз данных

PostgreSQL — объектно-реляционная система управления базами данных (СУБД), ведущая происхождение от проекта POSTGRES, который разрабатывался в Калифорнийском университете в Беркли под руководством профессора Майкла Стоунбрейкера 1. Реализация началась в 1986 году при поддержке DARPA, Армейского исследовательского управления (ARO), Национального научного фонда (NSF) и ESL, Inc. 1. Сегодня PostgreSQL называют самой продвинутой открытой СУБД 1, а в исследовательской среде она превратилась в стандартную платформу для сравнения и реализации новых идей оптимизации запросов 4.

Путь от демонстрационного прототипа до зрелой системы занял несколько десятилетий. Первая «демонстрационная» версия заработала в 1987 году и была показана на конференции ACM-SIGMOD в 1988-м 1. Версия 1 вышла в июне 1989 года для ограниченного круга внешних пользователей, версия 2 — в июне 1990 года с переработанной системой правил, а версия 3 — в 1991 году с поддержкой нескольких менеджеров хранения, улучшенным исполнителем запросов и переписанной системой правил 1.

В 1994 году Эндрю Ю и Джолли Чен добавили в POSTGRES интерпретатор языка SQL, и под новым именем Postgres95 система была выложена в открытый доступ 1. Код был полностью переписан на ANSI C и сокращён на 25%, а на тесте Wisconsin Benchmark версия 1.0.x работала примерно на 30–50% быстрее POSTGRES версии 4.2 1. В 1996 году систему переименовали в PostgreSQL, а нумерацию версий начали с 6.0, продолжая последовательность исходного проекта 1.

Архитектурная эволюция и сообщество

Проект POSTGRES с самого начала был тесно связан с исследованиями: начальные концепции системы, модель данных, система правил и архитектура менеджера хранения описывались в публикациях конца 1980-х годов 1. POSTGRES применялся в самых разных прикладных задачах — от анализа финансовых данных и мониторинга характеристик реактивных двигателей до баз данных для отслеживания астероидов, медицинских информационных систем и геоинформационных систем; использовался он и как учебный инструмент в университетах 1.

Коммерциализация тоже состоялась: код POSTGRES был подхвачен компанией Illustra Information Technologies, позже вошедшей в Informix, которым сейчас владеет IBM 1. В конце 1992 года POSTGRES стал основным менеджером данных для научного вычислительного проекта Sequoia 2000 1.

К 1993 году внешнее сообщество пользователей почти удвоилось, и поддержка прототипного кода стала отнимать слишком много времени у исследователей 1. Официально проект в Беркли завершился на версии 4.2 1. Дальнейшее развитие перешло к открытому сообществу, и акцент сместился с поиска и понимания проблем в коде сервера на наращивание функциональности 1.

Соответствие стандарту SQL

Формальное название стандарта SQL — ISO/IEC 9075 «Database Language SQL»; последняя редакция вышла в 2023 году и обозначается как SQL:2023 2. Предыдущие версии — SQL:2016, SQL:2011, SQL:2008, SQL:2006, SQL:2003, SQL:1999 и SQL-92 — заменяются новой, поэтому заявления о соответствии старым редакциям официальной силы не имеют 2. Разработчики PostgreSQL стремятся соответствовать последней официальной версии стандарта там, где это не противоречит традиционным возможностям системы или здравому смыслу 2.

Начиная с SQL:1999 стандарт определяет множество отдельных возможностей, а не три широких уровня (Entry, Intermediate, Full), как в SQL-92 2. Ядро PostgreSQL покрывает части 1, 2, 9, 11 и 14 стандарта; часть 3 покрывается драйвером ODBC, часть 13 — плагином PL/Java, хотя точное соответствие для этих компонентов сейчас не проверяется, а реализаций частей 4, 10, 15 и 16 для PostgreSQL нет 2.

Из 177 обязательных возможностей, необходимых для полного соответствия ядру SQL:2023, PostgreSQL поддерживает как минимум 170 2. При этом на момент написания документации ни одна актуальная версия какой-либо СУБД не заявляет о полном соответствии ядру SQL:2023 2. Списки поддерживаемых и неподдерживаемых возможностей в документации приблизительны: по отдельным деталям поддержанная функция может не соответствовать стандарту, а неподдержанная — быть реализованной в значительной части 2.

Инструменты вокруг сервера

Экосистема PostgreSQL включает набор клиентских приложений и утилит, которые можно запускать на любом хосте независимо от того, где находится сервер баз данных 3. Среди них — psql для интерактивных SQL-запросов, pg_dump и pg_dumpall для экспорта баз данных, pg_restore для восстановления из архива, pg_basebackup для создания базовой резервной копии кластера и pg_verifybackup для проверки её целостности 3.

Отдельные утилиты отвечают за администрирование и диагностику: createdb и dropdb создают и удаляют базы, createuser и dropuser управляют учётными записями, clusterdb кластеризует базу, reindexdb переиндексирует её, vacuumdb выполняет сборку мусора и анализ, pg_amcheck проверяет базы на наличие повреждений, а pg_isready — статус соединения с сервером 3. Для потоковой передачи журналов упреждающей записи (WAL) и управления потоками логического декодирования предназначены pg_receivewal и pg_recvlogical, для бенчмарков — pgbench, а pg_combinebackup собирает полную резервную копию из инкрементальной и зависимых от неё копий 3.

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

PostgreSQL как исследовательская платформа

За последнее десятилетие в оптимизации запросов наметились две тенденции: применение методов машинного обучения для замены компонентов традиционного оптимизатора и превращение PostgreSQL в стандартную СУБД — либо как базовую линию для бенчмарков, либо как целевую платформу для реализации 4. Проблема в том, что большинство новых концепций встраивается непосредственно в конкретные версии PostgreSQL, из-за чего сообщество получило разнородный «зоопарк» оптимизационных идей, которые трудно сравнивать: реализации несовместимы, опираются на разные версии, не документируют изменения в базовой системе или зависят от собственного инструментария 4.

Туториал на конференции SIGMOD 2025 предлагает выход: суммировать характеристики архитектуры оптимизатора PostgreSQL с акцентом на точки расширения, обозреть недавние исследования по улучшению традиционной архитектуры оптимизатора и показать, как предложенные концепции можно выразить в новом фреймворке оптимизации для сравнения на общей основе и быстрого прототипирования 4. Авторы подчёркивают важность воспроизводимых и открыто доступных прототипов, а также честных и прозрачных бенчмарков 4.

Ограничения и что важно учитывать

Документация, на которой основана эта статья, помечена как относящаяся к неподдерживаемой версии PostgreSQL 1, 2, 3, поэтому конкретные детали могут отличаться в актуальных релизах. Сведения о соответствии SQL:2023 приблизительны по признанию самих авторов документации: списки возможностей не дают полной картины, а официальная проверка соответствия для ряда компонентов не проводится 2. Утверждение о том, что PostgreSQL — «самая продвинутая открытая СУБД», принадлежит документации проекта и является оценочным 1.

Данные о тенденциях в исследованиях оптимизаторов получены из описания одного туториала и не претендуют на исчерпывающий обзор области 4. Наконец, в статье намеренно не обсуждаются коммерческие продукты и рыночные события вокруг PostgreSQL: они не входят в круг источников, использованных для этого текста.

Что дальше

Для читателей, которые хотят разобраться в теме глубже, логично начать с официальной документации: истории проекта 1, приложения о соответствии SQL 2 и справочника по клиентским приложениям 3. Исследователям, работающим над оптимизаторами запросов, стоит обратить внимание на проблему воспроизводимости прототипов и на усилия по созданию общей платформы для сравнения оптимизационных концепций 4.