Публикация была переведена автоматически. Исходный язык: Русский
У PostgreSQL есть редкое для инфраструктурных продуктов свойство: он не растёт за счёт одной “магической фичи”. Его успех сложился из нескольких инженерных решений, которые усиливают друг друга. В официальной документации PostgreSQL прямо сказано, что база держит согласованность через MVCC, где чтение не блокирует запись и запись не блокирует чтение; что система каталог-ориентирована и потому расширяема пользователем; что логическая репликация даёт тонкий контроль над потоками данных; что PostgreSQL соответствует как минимум 170 из 177 обязательных требований SQL:2023 Core; и что проект выпускает новый major примерно раз в год, а minor-обновления — как минимум раз в квартал, с длинным окном поддержки для каждой major-ветки. Это и есть не “маркетинговый успех”, а инженерная формула зрелости: предсказуемость, расширяемость, корректная конкурентность и дисциплина релизов.
Если свести это к одной мысли, PostgreSQL выиграл не потому, что всегда был самым быстрым на каждом частном бенчмарке. Он выиграл потому, что стал платформой, в которой можно одновременно строить OLTP, аналитику, репликацию, расширения, новые типы данных и сложные SQL-сценарии — и всё это без постоянного ощущения, что продукт живёт на временных костылях. Официальная страница “About” фактически описывает именно такой профиль: от MVCC, WAL и логической репликации до GIN/GiST/BRIN, JSON/JSONB, процедурных языков и FDW.
Четыре причины успеха PostgreSQL
| Основа | Что это даёт на практике |
| MVCC и SSI | Высокую конкурентность без постоянной войны между читающими и пишущими транзакциями |
| Каталог-ориентированная расширяемость | Возможность добавлять типы, функции, access methods и расширения, а не ждать вендора |
| Высокая SQL-совместимость | PostgreSQL развивается как СУБД общего назначения, а не как “диалект с удобствами” |
| Жёсткая релизная дисциплина | Предсказуемые апгрейды, длинная поддержка и доверие со стороны production-команд |
Эта таблица — не интерпретация “из воздуха”, а сжатый вывод из того, что PostgreSQL сам считает своими базовыми принципами: MVCC и SSI в разделе про concurrency, catalog-driven extensibility в разделе про extensibility, SQL:2023 Core conformance на странице About и annual-major/quarterly-minor cadence в versioning policy.
Что 18-я версия говорит о нынешнем характере развития
PostgreSQL 18 важен не только как очередной релиз, а как довольно честный снимок приоритетов проекта. В release notes в overview вынесены AIO, сохранение optimizer statistics в pg_upgrade, skip scan для multicolumn B-tree, uuidv7(), виртуальные generated columns, OAuth authentication, OLD/NEW в RETURNING и temporal constraints. Это очень показательный набор: в одном релизе одновременно улучшаются движок исполнения, миграции, SQL-поверхность, безопасность и работа с современными типами идентификаторов.
Самый заметный технический сигнал 18-й ветки — это новый AIO subsystem. PostgreSQL прямо пишет, что AIO помогает sequential scans, bitmap heap scans, vacuum и другим операциям; в beta announcement отдельно указано, что на Linux может использоваться io_uring, а тесты показывали прирост до 2–3x, тогда как релизный анонс говорит о приросте “up to 3x in certain scenarios”. Важно не только число, а сам вектор: PostgreSQL больше не просто “умно планирует запросы”, он всё глубже работает с реальной стоимостью I/O и с тем, как современные хранилища и CPU влияют на СУБД.
Не менее важен и operational angle. В 18-й версии pg_upgrade теперь сохраняет optimizer statistics, а логическая репликация получила целую серию практических улучшений: репликацию generated columns, переключение default streaming mode у CREATE SUBSCRIPTION на parallel, логирование конфликтов при apply и дополнительные возможности у pg_createsubscriber и pg_recvlogical, включая --enable-failover. Это очень зрелый тип эволюции: не “добавить экзотическую фичу”, а сделать upgrade и HA/replication менее болезненными в реальном проде.
Отсюда и главный вывод по 18-й версии: PostgreSQL уже давно развивается не как просто “open source relational database”, а как инфраструктурная платформа, где performance, correctness, migration cost и operability считаются частями одной задачи. Именно это и отличает зрелый проект от фреймворка, живущего циклами моды.
Что реально показывают CommitFest’ы 18, 19 и 20
Данные CommitFest — это не “число уникальных будущих фич”. Это workflow-метрики: сколько патчей в конкретном окне было committed, сколько moved to next CF, сколько осталось в review или ушло к автору. Один и тот же патч может переезжать через несколько окон; это хорошо видно по историям session variables, IVM, row pattern recognition и XMLDocument. Поэтому CommitFest — это не счётчик “новинок”, а лучший открытый источник для понимания того, как PostgreSQL принимает решения и как быстро доводит идеи до mainline.
Для 18-го цикла я взял все decision windows от 2024-07 до 2025-03; для 19-го — PG19-Drafts и PG19-1…PG19-Final; для 20-го — PG20-Drafts и текущий PG20-1. Такой разрез подтверждается историей CommitFest: цикл 18 ещё идёт в старом месячном формате, а начиная с 19-й ветки процесс уже стал релизно-именованным — с отдельными Drafts и Final.
Сводка по CommitFest-циклам 18, 19 и 20
| Цикл | Окна | Наблюдение |
| PG18 | 2024-07, 2024-09, 2024-11, 2025-01, 2025-03 | В конце цикла резко растёт доля committed: мартовский CF дал 154 committed при total 343, то есть около 45% |
| PG19 | PG19-Drafts, PG19-1, PG19-2, PG19-3, PG19-4, PG19-Final | Самый крупный decision window — PG19-Final: total 501 и committed 182; это крупнейшая точка закрытия из всего набора |
| PG20 | PG20-Drafts, PG20-1 | Цикл только формируется: в PG20-Drafts 14 активных патчей, а в PG20-1 total 356, но committed пока лишь 21 — очередь большая, решения ещё впереди |
По decision windows картина получается довольно жёсткая. У PG18 средняя доля committed по окнам находится примерно на уровне 29%, у PG19 — тоже около 30%; то есть сама “машина принятия изменений” выглядит достаточно стабильной. Но финальные окна важнее середины цикла: 2025-03 для 18-й ветки и PG19-Final для 19-й — это моменты, где PostgreSQL особенно активно превращает долго зревшие патчи в зафиксированные решения. Одновременно видно и другое: moved-to-next-CF почти всегда очень велик. Это означает, что проект системно предпочитает переносить спорные или недозревшие идеи, а не форсировать включение перед релизом.
Именно это, на мой взгляд, и есть одна из самых недооценённых причин успеха PostgreSQL. У многих open source проектов open process означает хаос. У PostgreSQL open process означает медленный, местами упрямый, но воспроизводимый конвейер: идея проходит через много окон, получает рецензии, rebases, передвигается дальше и либо дорастает до committed, либо остаётся жить в очереди. Это видно не по лозунгам, а по длинным историям конкретных патчей.
Куда PostgreSQL идёт по данным 19-й и 20-й веток
1. Он продолжает расширять SQL, а не только “ускорять железо”
Самый важный факт здесь — в PG19-Final был committed патч по SQL Property Graph Queries (SQL/PGQ). В том же цикле ранее был committed IGNORE NULLS для window functions, а в PG20-1 патч Add XMLDocument (SQL/XML X030) уже имеет статус Ready for Committer. Параллельно патч Implement row pattern recognition feature тянется через длинную цепочку CommitFest’ов и сейчас находится в PG20-1 со статусом Needs review. Это говорит о довольно последовательной линии: PostgreSQL не отказывается от роли “серьёзной SQL-платформы” и продолжает инвестировать в стандартные, сложные и дорого рецензируемые части языка.
Это важнее, чем кажется. Многие базы умеют быстро добавить удобный синтаксический сахар. PostgreSQL же тратит годы на вещи вроде row pattern recognition или SQL/PGQ именно потому, что такие возможности нельзя встраивать “на авось”: они затрагивают parser, planner, optimizer, semantics и совместимость. Консерватизм здесь — не тормоз, а цена качества. Это уже мой вывод, но он прямо опирается на историю патчей: row pattern recognition создан в 2023 году, пережил длинную цепочку переносов и всё ещё не форсирован в релиз.
2. Репликация становится одной из центральных осей развития
Логическая репликация уже давно перестала быть “дополнительной возможностью”, и по очереди патчей это видно очень ясно. В PG19-Final committed патч Support EXCEPT tables in publications; там же были committed изменения вокруг logical replication и slotsync worker. В PG20-Drafts активен крупный патч Parallel apply, а в PG20-1 продолжает жить Support automatic sequence replication, который переехал туда из PG19-Final. На уровне release notes 18-й версии эта же линия уже проявилась в changed default streaming mode, репликации generated columns и дополнительных failover-oriented утилитах.
Это, пожалуй, самый важный стратегический вектор ближайших лет. PostgreSQL явно движется к тому, чтобы replication/HA были не набором частных механизмов, а цельной производственной системой: с более тонким управлением, с лучшей observability, с меньшим числом ручных дыр вокруг sequence state, publications и apply behavior. Для современных распределённых приложений это важнее, чем ещё один локальный micro-optimization planner’а.
3. Наблюдаемость и операционная управляемость растут так же быстро, как SQL-функциональность
Если смотреть не на рекламируемые headline-фичи, а на реально проходящие патчи, видно сильное давление в сторону introspection и наблюдаемости. В PG19-Final были committed pg_stat_autovacuum_priority, несколько исправлений вокруг stats views и патч log_min_messages per backend type; в PG20-1 есть предложения вроде New pg_stat_tablespace view for tablespace level metrics, pg_stat_statements: add last_execution_start column, а также трекинг skipped vacuum/analyze. Это классический почерк зрелой СУБД: развитие идёт не только “в глубину движка”, но и в сторону более детального self-observation.
На практике это значит очень простую вещь: PostgreSQL всё лучше объясняет, что он делает, почему он это делает и где у него болит. Для больших инсталляций именно этот слой часто определяет, насколько дёшево сопровождать систему после того, как закончился первоначальный восторг от выбора технологии.
4. Проект аккуратно щупает новые архитектуры хранения, но не ломает ядро ради моды
Самый интересный пример здесь — VCI (columnar store extension), который сейчас в PG20-Drafts имеет статус Needs review и очень большой patch footprint. Это важный сигнал: у сообщества есть интерес к columnar-направлению, но этот интерес проходит через расширение и review-процесс, а не через резкий разворот ядра. Похожим образом и с IVM: тема востребована давно, но даже очень полезная идея incremental view maintenance не “продавлена” в релиз без многолетнего цикла обсуждений и доработки.
Такой подход может раздражать тех, кто ждёт мгновенного road-to-market. Но именно он объясняет, почему PostgreSQL почти никогда не выглядит как проект, который переобещал и сломал полсистемы. Он предпочитает медленное включение сильных идей, а не быстрый фейерверк новых аббревиатур. Это опять же вывод, но основанный на наблюдаемом процессе: VCI, IVM, session variables и row pattern recognition живут в публичном review годами.
Самые показательные патчи как индикаторы направления
| Патч | Текущее состояние | Почему это важно |
| SQL Property Graph Queries (SQL/PGQ) | Committed в PG19-Final | PostgreSQL расширяет SQL-ядро в сторону сложных стандартных запросов по графам |
| Add XMLDocument (SQL/XML X030) | Ready for Committer в PG20-1 | Стандартизация SQL/XML не брошена, а последовательно дожимается |
| Implement row pattern recognition feature | Needs review в PG20-1 | Проект готов инвестировать в тяжёлый SQL standard work даже ценой многолетнего review |
| Parallel apply | Needs review в PG20-Drafts | Репликация становится параллельной и ближе к high-throughput production-сценариям |
| Support automatic sequence replication | Needs review в PG20-1 | Сообщество закрывает одну из самых болезненных operational-дыр logical replication |
| VCI (columnar store extension) | Needs review в PG20-Drafts | Идёт аккуратная разведка columnar-направления без резкого перелома архитектуры |
| declarative session variables, LET command | Needs review в PG20-1, история тянется с 2018 года | Очень хороший пример того, насколько PostgreSQL консервативен к спорным изменениям языка |
Сами статусы и истории этих патчей важнее, чем мнения о них. Они показывают, что будущее PostgreSQL — это не одна большая ставка, а несколько параллельных векторов: SQL standard, replication, observability, developer ergonomics и аккуратные эксперименты с архитектурой данных.
Так в чём же его настоящий успех?
Успех PostgreSQL в том, что он не обещает невозможного и не живёт за счёт шума. Он десятилетиями строит редкую комбинацию качеств: сильную модель конкурентности, расширяемость на уровне архитектуры, длинную поддержку, быстрое освоение полезных частей стандарта, серьёзную репликацию и очень дисциплинированный review pipeline. PostgreSQL 18 показал это на уровне релиза: AIO, upgrade-path, security, replication и SQL-расширения движутся одновременно. CommitFest по 19-й и 20-й веткам показывает то же на уровне процесса: проект активно берёт в работу большие идеи, но включает их только тогда, когда на них сходится review, benchmarking и operational sense.
Если формулировать совсем жёстко: PostgreSQL побеждает потому, что развивается как база данных для взрослых систем. Не для демо, не для хайпа, не для презентаций инвесторам, а для среды, где важны одновременно корректность, предсказуемость, миграции, расширяемость и стоимость эксплуатации. И именно поэтому его roadmap сегодня выглядит особенно сильным: проект идёт не в одну моду, а в глубину всей платформы.
У PostgreSQL есть редкое для инфраструктурных продуктов свойство: он не растёт за счёт одной “магической фичи”. Его успех сложился из нескольких инженерных решений, которые усиливают друг друга. В официальной документации PostgreSQL прямо сказано, что база держит согласованность через MVCC, где чтение не блокирует запись и запись не блокирует чтение; что система каталог-ориентирована и потому расширяема пользователем; что логическая репликация даёт тонкий контроль над потоками данных; что PostgreSQL соответствует как минимум 170 из 177 обязательных требований SQL:2023 Core; и что проект выпускает новый major примерно раз в год, а minor-обновления — как минимум раз в квартал, с длинным окном поддержки для каждой major-ветки. Это и есть не “маркетинговый успех”, а инженерная формула зрелости: предсказуемость, расширяемость, корректная конкурентность и дисциплина релизов.
Если свести это к одной мысли, PostgreSQL выиграл не потому, что всегда был самым быстрым на каждом частном бенчмарке. Он выиграл потому, что стал платформой, в которой можно одновременно строить OLTP, аналитику, репликацию, расширения, новые типы данных и сложные SQL-сценарии — и всё это без постоянного ощущения, что продукт живёт на временных костылях. Официальная страница “About” фактически описывает именно такой профиль: от MVCC, WAL и логической репликации до GIN/GiST/BRIN, JSON/JSONB, процедурных языков и FDW.
Четыре причины успеха PostgreSQL
| Основа | Что это даёт на практике |
| MVCC и SSI | Высокую конкурентность без постоянной войны между читающими и пишущими транзакциями |
| Каталог-ориентированная расширяемость | Возможность добавлять типы, функции, access methods и расширения, а не ждать вендора |
| Высокая SQL-совместимость | PostgreSQL развивается как СУБД общего назначения, а не как “диалект с удобствами” |
| Жёсткая релизная дисциплина | Предсказуемые апгрейды, длинная поддержка и доверие со стороны production-команд |
Эта таблица — не интерпретация “из воздуха”, а сжатый вывод из того, что PostgreSQL сам считает своими базовыми принципами: MVCC и SSI в разделе про concurrency, catalog-driven extensibility в разделе про extensibility, SQL:2023 Core conformance на странице About и annual-major/quarterly-minor cadence в versioning policy.
Что 18-я версия говорит о нынешнем характере развития
PostgreSQL 18 важен не только как очередной релиз, а как довольно честный снимок приоритетов проекта. В release notes в overview вынесены AIO, сохранение optimizer statistics в pg_upgrade, skip scan для multicolumn B-tree, uuidv7(), виртуальные generated columns, OAuth authentication, OLD/NEW в RETURNING и temporal constraints. Это очень показательный набор: в одном релизе одновременно улучшаются движок исполнения, миграции, SQL-поверхность, безопасность и работа с современными типами идентификаторов.
Самый заметный технический сигнал 18-й ветки — это новый AIO subsystem. PostgreSQL прямо пишет, что AIO помогает sequential scans, bitmap heap scans, vacuum и другим операциям; в beta announcement отдельно указано, что на Linux может использоваться io_uring, а тесты показывали прирост до 2–3x, тогда как релизный анонс говорит о приросте “up to 3x in certain scenarios”. Важно не только число, а сам вектор: PostgreSQL больше не просто “умно планирует запросы”, он всё глубже работает с реальной стоимостью I/O и с тем, как современные хранилища и CPU влияют на СУБД.
Не менее важен и operational angle. В 18-й версии pg_upgrade теперь сохраняет optimizer statistics, а логическая репликация получила целую серию практических улучшений: репликацию generated columns, переключение default streaming mode у CREATE SUBSCRIPTION на parallel, логирование конфликтов при apply и дополнительные возможности у pg_createsubscriber и pg_recvlogical, включая --enable-failover. Это очень зрелый тип эволюции: не “добавить экзотическую фичу”, а сделать upgrade и HA/replication менее болезненными в реальном проде.
Отсюда и главный вывод по 18-й версии: PostgreSQL уже давно развивается не как просто “open source relational database”, а как инфраструктурная платформа, где performance, correctness, migration cost и operability считаются частями одной задачи. Именно это и отличает зрелый проект от фреймворка, живущего циклами моды.
Что реально показывают CommitFest’ы 18, 19 и 20
Данные CommitFest — это не “число уникальных будущих фич”. Это workflow-метрики: сколько патчей в конкретном окне было committed, сколько moved to next CF, сколько осталось в review или ушло к автору. Один и тот же патч может переезжать через несколько окон; это хорошо видно по историям session variables, IVM, row pattern recognition и XMLDocument. Поэтому CommitFest — это не счётчик “новинок”, а лучший открытый источник для понимания того, как PostgreSQL принимает решения и как быстро доводит идеи до mainline.
Для 18-го цикла я взял все decision windows от 2024-07 до 2025-03; для 19-го — PG19-Drafts и PG19-1…PG19-Final; для 20-го — PG20-Drafts и текущий PG20-1. Такой разрез подтверждается историей CommitFest: цикл 18 ещё идёт в старом месячном формате, а начиная с 19-й ветки процесс уже стал релизно-именованным — с отдельными Drafts и Final.
Сводка по CommitFest-циклам 18, 19 и 20
| Цикл | Окна | Наблюдение |
| PG18 | 2024-07, 2024-09, 2024-11, 2025-01, 2025-03 | В конце цикла резко растёт доля committed: мартовский CF дал 154 committed при total 343, то есть около 45% |
| PG19 | PG19-Drafts, PG19-1, PG19-2, PG19-3, PG19-4, PG19-Final | Самый крупный decision window — PG19-Final: total 501 и committed 182; это крупнейшая точка закрытия из всего набора |
| PG20 | PG20-Drafts, PG20-1 | Цикл только формируется: в PG20-Drafts 14 активных патчей, а в PG20-1 total 356, но committed пока лишь 21 — очередь большая, решения ещё впереди |
По decision windows картина получается довольно жёсткая. У PG18 средняя доля committed по окнам находится примерно на уровне 29%, у PG19 — тоже около 30%; то есть сама “машина принятия изменений” выглядит достаточно стабильной. Но финальные окна важнее середины цикла: 2025-03 для 18-й ветки и PG19-Final для 19-й — это моменты, где PostgreSQL особенно активно превращает долго зревшие патчи в зафиксированные решения. Одновременно видно и другое: moved-to-next-CF почти всегда очень велик. Это означает, что проект системно предпочитает переносить спорные или недозревшие идеи, а не форсировать включение перед релизом.
Именно это, на мой взгляд, и есть одна из самых недооценённых причин успеха PostgreSQL. У многих open source проектов open process означает хаос. У PostgreSQL open process означает медленный, местами упрямый, но воспроизводимый конвейер: идея проходит через много окон, получает рецензии, rebases, передвигается дальше и либо дорастает до committed, либо остаётся жить в очереди. Это видно не по лозунгам, а по длинным историям конкретных патчей.
Куда PostgreSQL идёт по данным 19-й и 20-й веток
1. Он продолжает расширять SQL, а не только “ускорять железо”
Самый важный факт здесь — в PG19-Final был committed патч по SQL Property Graph Queries (SQL/PGQ). В том же цикле ранее был committed IGNORE NULLS для window functions, а в PG20-1 патч Add XMLDocument (SQL/XML X030) уже имеет статус Ready for Committer. Параллельно патч Implement row pattern recognition feature тянется через длинную цепочку CommitFest’ов и сейчас находится в PG20-1 со статусом Needs review. Это говорит о довольно последовательной линии: PostgreSQL не отказывается от роли “серьёзной SQL-платформы” и продолжает инвестировать в стандартные, сложные и дорого рецензируемые части языка.
Это важнее, чем кажется. Многие базы умеют быстро добавить удобный синтаксический сахар. PostgreSQL же тратит годы на вещи вроде row pattern recognition или SQL/PGQ именно потому, что такие возможности нельзя встраивать “на авось”: они затрагивают parser, planner, optimizer, semantics и совместимость. Консерватизм здесь — не тормоз, а цена качества. Это уже мой вывод, но он прямо опирается на историю патчей: row pattern recognition создан в 2023 году, пережил длинную цепочку переносов и всё ещё не форсирован в релиз.
2. Репликация становится одной из центральных осей развития
Логическая репликация уже давно перестала быть “дополнительной возможностью”, и по очереди патчей это видно очень ясно. В PG19-Final committed патч Support EXCEPT tables in publications; там же были committed изменения вокруг logical replication и slotsync worker. В PG20-Drafts активен крупный патч Parallel apply, а в PG20-1 продолжает жить Support automatic sequence replication, который переехал туда из PG19-Final. На уровне release notes 18-й версии эта же линия уже проявилась в changed default streaming mode, репликации generated columns и дополнительных failover-oriented утилитах.
Это, пожалуй, самый важный стратегический вектор ближайших лет. PostgreSQL явно движется к тому, чтобы replication/HA были не набором частных механизмов, а цельной производственной системой: с более тонким управлением, с лучшей observability, с меньшим числом ручных дыр вокруг sequence state, publications и apply behavior. Для современных распределённых приложений это важнее, чем ещё один локальный micro-optimization planner’а.
3. Наблюдаемость и операционная управляемость растут так же быстро, как SQL-функциональность
Если смотреть не на рекламируемые headline-фичи, а на реально проходящие патчи, видно сильное давление в сторону introspection и наблюдаемости. В PG19-Final были committed pg_stat_autovacuum_priority, несколько исправлений вокруг stats views и патч log_min_messages per backend type; в PG20-1 есть предложения вроде New pg_stat_tablespace view for tablespace level metrics, pg_stat_statements: add last_execution_start column, а также трекинг skipped vacuum/analyze. Это классический почерк зрелой СУБД: развитие идёт не только “в глубину движка”, но и в сторону более детального self-observation.
На практике это значит очень простую вещь: PostgreSQL всё лучше объясняет, что он делает, почему он это делает и где у него болит. Для больших инсталляций именно этот слой часто определяет, насколько дёшево сопровождать систему после того, как закончился первоначальный восторг от выбора технологии.
4. Проект аккуратно щупает новые архитектуры хранения, но не ломает ядро ради моды
Самый интересный пример здесь — VCI (columnar store extension), который сейчас в PG20-Drafts имеет статус Needs review и очень большой patch footprint. Это важный сигнал: у сообщества есть интерес к columnar-направлению, но этот интерес проходит через расширение и review-процесс, а не через резкий разворот ядра. Похожим образом и с IVM: тема востребована давно, но даже очень полезная идея incremental view maintenance не “продавлена” в релиз без многолетнего цикла обсуждений и доработки.
Такой подход может раздражать тех, кто ждёт мгновенного road-to-market. Но именно он объясняет, почему PostgreSQL почти никогда не выглядит как проект, который переобещал и сломал полсистемы. Он предпочитает медленное включение сильных идей, а не быстрый фейерверк новых аббревиатур. Это опять же вывод, но основанный на наблюдаемом процессе: VCI, IVM, session variables и row pattern recognition живут в публичном review годами.
Самые показательные патчи как индикаторы направления
| Патч | Текущее состояние | Почему это важно |
| SQL Property Graph Queries (SQL/PGQ) | Committed в PG19-Final | PostgreSQL расширяет SQL-ядро в сторону сложных стандартных запросов по графам |
| Add XMLDocument (SQL/XML X030) | Ready for Committer в PG20-1 | Стандартизация SQL/XML не брошена, а последовательно дожимается |
| Implement row pattern recognition feature | Needs review в PG20-1 | Проект готов инвестировать в тяжёлый SQL standard work даже ценой многолетнего review |
| Parallel apply | Needs review в PG20-Drafts | Репликация становится параллельной и ближе к high-throughput production-сценариям |
| Support automatic sequence replication | Needs review в PG20-1 | Сообщество закрывает одну из самых болезненных operational-дыр logical replication |
| VCI (columnar store extension) | Needs review в PG20-Drafts | Идёт аккуратная разведка columnar-направления без резкого перелома архитектуры |
| declarative session variables, LET command | Needs review в PG20-1, история тянется с 2018 года | Очень хороший пример того, насколько PostgreSQL консервативен к спорным изменениям языка |
Сами статусы и истории этих патчей важнее, чем мнения о них. Они показывают, что будущее PostgreSQL — это не одна большая ставка, а несколько параллельных векторов: SQL standard, replication, observability, developer ergonomics и аккуратные эксперименты с архитектурой данных.
Так в чём же его настоящий успех?
Успех PostgreSQL в том, что он не обещает невозможного и не живёт за счёт шума. Он десятилетиями строит редкую комбинацию качеств: сильную модель конкурентности, расширяемость на уровне архитектуры, длинную поддержку, быстрое освоение полезных частей стандарта, серьёзную репликацию и очень дисциплинированный review pipeline. PostgreSQL 18 показал это на уровне релиза: AIO, upgrade-path, security, replication и SQL-расширения движутся одновременно. CommitFest по 19-й и 20-й веткам показывает то же на уровне процесса: проект активно берёт в работу большие идеи, но включает их только тогда, когда на них сходится review, benchmarking и operational sense.
Если формулировать совсем жёстко: PostgreSQL побеждает потому, что развивается как база данных для взрослых систем. Не для демо, не для хайпа, не для презентаций инвесторам, а для среды, где важны одновременно корректность, предсказуемость, миграции, расширяемость и стоимость эксплуатации. И именно поэтому его roadmap сегодня выглядит особенно сильным: проект идёт не в одну моду, а в глубину всей платформы.
Поделиться
