The post has been translated automatically. Original language: Russian
PostgreSQL has a rare property for infrastructure products: it does not grow due to one “magic feature”. His success has been made up of several engineering solutions that reinforce each other. The official PostgreSQL documentation explicitly states that the database maintains consistency through MVCC, where reading does not block writing and writing does not block reading; that the system is directory-oriented and therefore user-extensible; that logical replication gives fine control over data flows; that PostgreSQL meets at least 170 of the 177 mandatory requirements of SQL:2023 Core; and that the project releases a new major about once a year, and minor updates at least once a quarter, with a long support window for each major branch. This is not a “marketing success”, but an engineering formula for maturity: predictability, extensibility, correct competitiveness and release discipline.
To put it into one thought, PostgreSQL didn't win because it was always the fastest on every private benchmark. It won because it became a platform where you can simultaneously build OLTP, analytics, replication, extensions, new data types, and complex SQL scripts - all without constantly feeling like the product is living on temporary crutches. The official About page actually describes exactly such a profile: from MVCC, WAL, and logical replication to GIN/GiST/BRIN, JSON/JSONB, procedural languages, and FDW.
Four reasons for the success of PostgreSQL
| Base | What does this mean in practice? |
| MVCC and SSI | High competitiveness without a constant war between reading and writing transactions |
| Catalog-oriented extensibility | The ability to add types, functions, access methods, and extensions, rather than waiting for a vendor. |
| High SQL compatibility | PostgreSQL is developing as a general-purpose DBMS, not as a “dialect with convenience” |
| Strict release discipline | Predictable upgrades, long-term support and trust from the production teams |
This table is not an interpretation “out of thin air”, but a concise conclusion from what PostgreSQL itself considers its basic principles: MVCC and SSI in the section on concurrency, catalog-driven extensibility in the section on extensibility, SQL:2023 Core conformance on the About page and annual-major/quarterly-minor cadence in versioning policy.
What does version 18 say about the current nature of development
PostgreSQL 18 is important not only as another release, but as a fairly honest snapshot of the project's priorities. In release notes, the overview includes AIO, saving optimizer statistics to pg_upgrade, skip scan for the multicolumn B-tree, uuidv7(), virtual generated columns, OAuth authentication, OLD/NEW in RETURNING, and temporal constraints. This is a very revealing set: in one release, the execution engine, migrations, SQL-surface, security, and work with modern types of identifiers are simultaneously improved.
The most noticeable technical signal of the 18th branch is the new AIO subsystem. PostgreSQL explicitly writes that AIO helps sequential scans, bitmap heap scans, vacuum and other operations; the beta announcement specifically states that io_uring can be used on Linux, and tests showed an increase to 2-3 x, while the release announcement speaks of an increase “up to 3x in certain scenarios". It's not just the number that matters, but the vector itself: PostgreSQL is no longer just “smartly scheduling queries”, it is increasingly working with the real cost of I/O and how modern storage and CPU affect DBMS.
The operational angle is equally important. In version 18, pg_upgrade now retains optimizer statistics, and logical replication has received a series of practical improvements: replication of generated columns, switching the default streaming mode from CREATE SUBSCRIPTION to parallel, logging conflicts with apply, and additional features for pg_createsubscriber and pg_recvlogical, including --enable-failover. This is a very mature type of evolution: not to “add an exotic feature”, but to make upgrade and HA/replication less painful in real production.
Hence the main conclusion of the 18th version: PostgreSQL has long been developing not as just an “open source relational database”, but as an infrastructure platform where performance, correctness, migration cost and operability are considered parts of the same task. This is what distinguishes a mature project from a framework that lives in fashion cycles.
What CommitFests on 18, 19 and 20 really show
CommitFest data is not a “number of unique future features.” These are workflow metrics: how many patches in a particular window were committed, how many moved to next CF, how many remained in the review or went to the author. The same patch can move through multiple windows; this is clearly seen in the histories of session variables, IVM, row pattern recognition, and XmlDocument. Therefore, CommitFest is not a counter of “new products”, but the best open source for understanding how PostgreSQL makes decisions and how quickly it brings ideas to the mainline.
For the 18th cycle, I took all decision windows from 2024-07 to 2025-03; for the 19th, PG19-Drafts and PG19—1...PG19-Final; for the 20th— PG20-Drafts and the current PG20-1. This cut is confirmed by the history of CommitFest: cycle 18 is still running in the old monthly format, and starting from the 19th branch, the process has already become release-named - with separate Drafts and Final.
Summary of CommitFest cycles 18, 19 and 20
| Cycle | Windows | Observation |
| PG18 | 2024-07, 2024-09, 2024-11, 2025-01, 2025-03 | At the end of the cycle, the committed share increases sharply: the March CF gave 154 committed with a total of 343, that is, about 45% |
| PG19 | PG19-Drafts, PG19-1, PG19-2, PG19-3, PG19-4, PG19-Final | The largest decision window is PG19—Final: total 501 and committed 182; this is the largest closing point of the entire set |
| PG20 | PG20-Drafts, PG20-1 | The cycle is just forming: there are 14 active patches in PG20-Drafts, and a total of 356 in PG20-1, but only 21 are committed so far — the queue is large, solutions are still ahead. |
According to decision windows, the picture turns out to be quite harsh. In PG18, the average committed share for windows is about 29%, in PG19 it is also about 30%; that is, the “change acceptance machine” itself looks quite stable. But the final windows are more important than the middle of the cycle: 2025-03 for the 18th branch and PG19-Final for the 19th are the moments where PostgreSQL is particularly active in turning long-overdue patches into fixed solutions. At the same time, something else is visible: moved-to-next-CF is almost always very large. This means that the project systematically prefers to transfer controversial or immature ideas rather than force inclusion before release.
This, in my opinion, is one of the most overlooked reasons for the success of PostgreSQL. For many open source projects, open process means chaos. For PostgreSQL, open process means a slow, sometimes stubborn, but reproducible pipeline: an idea goes through many windows, receives reviews, rebases, moves on and either grows to committed, or remains alive in the queue. This is evident not from the slogans, but from the long stories of specific patches.
Where is PostgreSQL going according to the 19th and 20th branches
1. It continues to expand SQL, not just “accelerate hardware”
The most important fact here is that in PG19—Final there was a committed patch on SQL Property Graph Queries (SQL/PGQ). In the same cycle, there was previously a committed IGNORE NULLS for window functions, and in PG20-1, the Add XmlDocument patch (SQL/XML X030) already has the Ready for Commit status. In parallel, the patch Implementation row pattern recognition feature stretches through a long chain of CommitFests and is currently in PG20-1 with the status of Needs review. This suggests a fairly consistent line: PostgreSQL does not abandon the role of a “serious SQL platform” and continues to invest in standard, complex and expensive peer-reviewed parts of the language.
This is more important than it seems. Many databases are able to quickly add convenient syntactic sugar. PostgreSQL spends years on things like row pattern recognition or SQL/PGQ precisely because such features cannot be built in “at random”: they affect parser, planner, optimizer, semantics and compatibility. Conservatism here is not a drag, but the price of quality. This is my conclusion, but it is directly based on the patch history.: row pattern recognition was created in 2023, has gone through a long chain of postponements and is still not forced into release.
2. Replication is becoming one of the central axes of development
Logical replication has long ceased to be an “additional feature”, and this can be seen very clearly from the sequence of patches. In PG19, the Final committed patch supports EXCEPT tables in publications; there were also committed changes around logical replication and slotsync worker. A major Parallel apply patch is active in PG20-Drafts, and Support automatic sequence replication, which moved there from PG19-Final, continues to live in PG20-1. At the release notes level of version 18, the same line has already manifested itself in the changed default streaming mode, replication of generated columns, and additional failover-oriented utilities.
This is perhaps the most important strategic vector of the coming years. PostgreSQL is clearly moving towards ensuring that replication/HA is not a set of private mechanisms, but a complete production system: with finer management, better observability, and fewer manual holes around sequence state, publications, and apply behavior. For In modern distributed applications, this is more important than another local micro-optimization planner.
3. Observability and operational manageability are growing as fast as SQL functionality.
If you look not at the advertised headline features, but at the actual patches, you can see a lot of pressure towards introspection and observability. In PG19-Final, pg_stat_autovacuum_priority was committed, several fixes around stats views and the log_min_messages per backend type patch; in PG20-1, there are proposals like New pg_stat_tablespace view for tablespace level metrics, pg_stat_statements: add last_execution_start column, as well as skipped vacuum/analyze tracking. This is the classic handwriting of a mature DBMS: development goes not only “into the depths of the engine”, but also towards more detailed self-observation.
In practice, this means a very simple thing: PostgreSQL is getting better at explaining what it does, why it does it, and where it hurts. For large installations, it is this layer that often determines how cheap it is to maintain the system after the initial excitement of choosing the technology has ended.
4. The project carefully examines new storage architectures, but does not break the core for the sake of fashion
The most interesting example here is the VCI (columnar store extension), which currently has the Needs review status and a very large patch footprint in PG20—Drafts. This is an important signal.: The community has an interest in the columnar direction, but this interest goes through the expansion and review process, and not through a sharp reversal of the core. In a similar way with IVM: the topic has been in demand for a long time, but even the very useful idea of incremental view maintenance is not “pushed” into the release without a multi-year cycle of discussions and refinement.
This approach may annoy those who are waiting for an instant road-to-market. But he explains why PostgreSQL almost never looks like a project that has reinvented and broken half the system. He prefers the slow incorporation of strong ideas rather than the rapid fireworks of new acronyms. This is again a conclusion, but based on an observed process: VCI, IVM, session variables, and row pattern recognition have been living in public review for years.
The most significant patches as indicators of direction
| The patch | Current status | Why is this important? |
| SQL Property Graph Queries (SQL/PGQ) | Committed in PG19-Final | PostgreSQL expands the SQL core towards complex standard graph queries |
| Add XMLDocument (SQL/XML X030) | Ready for Committer in PG20-1 | SQL/XML standardization has not been abandoned, but is being consistently pressed. |
| Implement row pattern recognition feature | Needs review in PG20-1 | The project is ready to invest in heavy SQL standard work even at the cost of a multi-year review |
| Parallel apply | Needs review in PG20-Drafts | Replication is becoming parallel and closer to high-throughput production scenarios |
| Support automatic sequence replication | Needs review in PG20-1 | The community is closing one of the most painful operational holes, logical replication |
| VCI (columnar store extension) | Needs review in PG20-Drafts | There is a careful exploration of the columnar direction without a sharp change in architecture. |
| declarative session variables, LET command | Needs review in PG20-1, the story stretches back to 2018 | This is a very good example of how conservative PostgreSQL is towards controversial language changes. |
The statuses and stories of these patches themselves are more important than opinions about them. They show that the future of PostgreSQL is not one big bet, but several parallel vectors: SQL standard, replication, observability, developer ergonomics, and careful experiments with data architecture.
So what is his real success?
The success of PostgreSQL is that it does not promise the impossible and does not live off noise. For decades, he has been building a rare combination of qualities: a strong competitive model, extensibility at the architecture level, long support, rapid development of useful parts of the standard, serious replication and a very disciplined review pipeline. PostgreSQL 18 showed this at the release level: AIO, upgrade-path, security, replication, and SQL extensions are moving simultaneously. CommitFest on the 19th and 20th branches shows the same thing at the process level: the project actively takes big ideas into work, but includes them only when review, benchmarking and operational sense converge on them.
To put it very harshly: PostgreSQL wins because it develops as a database for adult systems. Not for demo, not for HYPE, not for presentations to investors, but for an environment where correctness, predictability, migration, extensibility and cost of operation are important at the same time. And that's why his roadmap looks especially strong today: the project goes not in one fashion, but into the depths of the entire platform.
У 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 сегодня выглядит особенно сильным: проект идёт не в одну моду, а в глубину всей платформы.
Share
