РАЗРАБОТКА

Как Postgres пережил создателей и стал опорой облаков

30 лет волонтерской разработки превратили Postgres из академического проекта в базу облачных сервисов AWS, Azure и Google Cloud.

✍️ Редакция iTech News | 23.06.2026 | ⏱ 5 мин | Источник: The Register

База данных Postgres прожила редкий для инфраструктурного софта сюжет: создатель фактически отошел от проекта еще в середине 1990-х, а через три десятилетия именно на этой платформе работают сервисы AWS, Microsoft Azure и Google Cloud. Для российских разработчиков и ИТ-руководителей это не просто красивая история open source, а наглядное объяснение, почему база данных Postgres стала стандартным выбором там, где нужны совместимость, контроль над стеком и запас прочности на годы вперед.

Эту историю на конференции PGDay в Бостоне пересказал Майкл Стоунбрейкер, один из главных людей в мире СУБД, создатель Ingres и Postgres, сообщает The Register. По его словам, Postgres в каком-то смысле стал квинтэссенцией открытого ПО именно потому, что проект не принадлежал никому конкретно: не корпорации, не фонду с жесткой вертикалью, не одному вендору. Сам Стоунбрейкер фактически оставил Postgres в середине 1990-х. Если бы код тогда просто лег на полку, история закончилась бы еще одним академическим артефактом уровня «интересно, но не взлетело». Вместо этого проект подхватило сообщество разработчиков, которое сохранило архитектурную идею и дотащило систему до статуса одной из самых популярных СУБД в мире.

Чтобы понять, почему это вообще важно, надо вернуться в 1970 год. Тогда британский ученый Тед Кодд, работавший в IBM, сформулировал реляционную модель: данные должны храниться в таблицах и запрашиваться через язык высокого уровня. IBM пошла этим путем в System R и позже довела идеи до DB2. Стоунбрейкер, в тот момент доцент Калифорнийского университета в Беркли, занялся своей реализацией тех же принципов. Так появился Ingres, а затем и одноименный стартап Relational Technology. У Ingres был не SQL, а язык QUEL, но логика была той же: реляционная модель как основа работы с корпоративными данными. В начале 1980-х Стоунбрейкер, по его собственному выражению, буквально «столкнул код с обрыва» и решил строить новую систему. Так родился Postgres, то есть Post-Ingres.

Причина была не в желании просто переписать старый продукт с нуля. Бизнесу уже не хватало набора из целых чисел, строк и простых финансовых таблиц. На подходе были CAD-системы, геоданные, более сложные структуры, которые плохо укладывались в классическую бухгалтерскую картину мира. Стоунбрейкер и его коллеги решили, что СУБД должна уметь расширяться: добавлять новые типы данных, пользовательские операторы и функции, а главное, учить этому оптимизатор запросов. Именно здесь и возникла одна из ключевых идей Postgres — поддержка abstract data types, или абстрактных типов данных. Стоунбрейкер прямо говорит, что именно эта работа, вероятно, стала главным основанием для премии Тьюринга, которую он получил в 2014 году. И если смотреть на современный рынок без академического пафоса, его трудно упрекнуть в самоуверенности: поддержка расширяемости давно стала нормой для индустрии, а не экзотикой из университетской лаборатории.

При этом ранний Postgres вовсе не выглядел безусловным победителем. Стоунбрейкер с партнерами пытался монетизировать разработку через стартап Illustra, который позже купила Informix. Технология ушла в коммерческий продукт, а открытая ветка существовала скорее по инерции: термин open source тогда еще даже не был оформлен как индустриальный стандарт, а код распространялся как свободное академическое ПО под очень либеральной BSD-лицензией. Переломным моментом стал 1995 год, когда два аспиранта Беркли, Эндрю Ю и Джолли Чен, взяли последнюю академическую версию Postgres 4.2 и фактически перезапустили проект. Они выкинули неудачно работавшие правила и механизм восстановления после сбоев, а главное — заменили QUEL на SQL. Так появился Postgre95, а затем PostgreSQL. Стоунбрейкер отдельно подчеркивает, что с этой командой добровольцев он даже не был знаком. То есть у проекта не было ни централизованной передачи власти, ни красивого transition plan, ни корпоративного «спонсора трансформации». Была кодовая база и группа очень сильных инженеров, которые решили, что ее стоит спасти.

Дальше началось то, что особенно интересно бизнесу и архитекторам платформ. Именно отсутствие единственного хозяина сделало Postgres безопасной ставкой для рынка. На его интерфейсе и совместимости строились другие системы, включая CockroachDB, YugabyteDB и Timescale. Все три крупнейших облака — AWS, Azure и Google Cloud — имеют собственные database-as-a-service-предложения на базе PostgreSQL-совместимости. Это, пожалуй, главный комплимент технологии: гиганты конкурируют между собой, но все равно продают клиентам один и тот же знакомый API и один и тот же экосистемный язык. Стоунбрейкер сформулировал это грубо, но точно: «слоны поставили ранчо на Postgres». Даже графовая СУБД Amazon, по его словам, построена на Postgres. Для компаний это означает простую вещь: совместимость с PostgreSQL давно стала не приятной галочкой в спецификации, а билетом в облачную инфраструктуру и рынок инструментов вокруг нее.

Не менее показательно, почему именно Postgres удержался наверху, тогда как многие хорошие базы данных остались нишевыми. По данным DB-Engines, PostgreSQL находится в верхней части мирового рейтинга популярности СУБД — сразу за Oracle, MySQL и Microsoft SQL Server, но в отличие от части этих конкурентов продолжает наращивать долю. Том Кинкейд, один из организаторов PGDay и вице-президент EDB, объясняет это без магии. Во-первых, расширяемость помогла Postgres заходить в новые сценарии раньше других: сначала в геоданные, потом в документные нагрузки. Во-вторых, система быстро оказалась полезной разработчикам, когда приложениям понадобилась работа с JSON-документами без отказа от SQL. В-третьих, свою роль сыграли качество кодовой базы и строгий процесс ревью: сильные инженеры охотнее идут в проект, где архитектурные решения не разваливаются от каждой моды сезона. Наконец, BSD-лицензия убрала важный страх для стартапов и вендоров: на Postgres можно строить продукт, сервис и бизнес-модель, не опасаясь внезапного изменения правил игры со стороны владельца платформы.

Для русскоязычного ИТ-рынка в этой истории полезен не романтический миф о силе сообщества, а более приземленный вывод. Победила не просто «бесплатная база», а архитектура, которая позволила проекту пережить собственных авторов, смену технологических эпох и корпоративные войны вокруг данных. На фоне очередного бума вокруг ИИ и специализированных хранилищ это звучит почти старомодно, но именно такие свойства обычно и отделяют модный инструмент от инфраструктурного стандарта: можно ли на нем строить десятилетиями, не спрашивая разрешения у одного вендора и не переписывая все при следующем повороте рынка.

Поделиться: Telegram X LinkedIn