Привет! Если вы крутитесь в сфере веб-разработки хотя бы лет десять, то наверняка помните тот безумный хайп вокруг NoSQL баз данных. Примерно в 2013–2015 годах из каждого утюга кричали, что классические реляционные базы вроде MySQL и PostgreSQL — это неповоротливое легаси из прошлого века.
Нам твердили: «Мир изменился, данные стали гибкими! Таблицы и жесткие связи больше не нужны. Будущее за MongoDB, Redis и Cassandra! Переходите на документо-ориентированные базы, иначе ваш проект не выдержит нагрузок».
Индустрия дружно бросилась переписывать бэкенды. Стартапы лепили MongoDB везде, где надо и не надо, гордо называя это «современным стеком». Но прошло десять лет, хайп улегся, пыль осела. И что мы видим в актуальных проектах? Старый добрый PostgreSQL не просто выжил — он переживает колоссальный ренессанс и уверенно победил в этой войне.
Давайте разберем без занудства и маркетинговой чепухи, как скромный слоник из 90-х смог эволюционировать и уничтожить своих модных конкурентов.
Как NoSQL заставил Postgres измениться
Справедливости ради, NoSQL появился не на пустом месте. У него было два мощных козыря. Во-первых, гибкость: в ту же «Монгу» можно было записать документ абсолютно любого вида, не настраивая заранее структуру таблицы и типы данных. Во-вторых, скорость работы с простыми запросами из коробки.
Разработчики PostgreSQL посмотрели на этот праздник жизни и вместо того, чтобы признать поражение, сделали гениальный ход. Они начали внедрять лучшие фишки конкурентов прямо в свое ядро.
Главным ударом по NoSQL стало появление в Postgres продвинутого формата работы с документами — JSONB.
Это изменило всё. Зачем разработчику ставить отдельную, капризную базу данных MongoDB ради хранения гибких пользовательских настроек или корзины товаров, если теперь можно создать обычную таблицу в Postgres и в одну из колонок сохранять чистый JSON? При этом этот JSON сжимается, по нему можно строить полноценные индексы, и он работает с космической скоростью. Postgres забрал у NoSQL их главное оружие, сохранив при этом надежность, транзакции и строгие связи там, где они жизненно необходимы (например, в биллинге и деньгах).
Экосистема расширений: как Postgres стал «швейцарским ножом»
Но на JSONB история не закончилась. Архитектура PostgreSQL изначально проектировалась как расширяемая. Это значит, что сторонние разработчики могут писать для нее плагины, которые кардинально меняют возможности базы, не ломая её ядро.
За последние годы появилось несколько расширений, которые окончательно закрыли вопросы о необходимости других специализированных баз данных:
- Борьба с базами временных рядов (TimescaleDB). Если вашему проекту нужно хранить миллионы записей с датчиков умного дома, финансовые котировки или логи каждую миллисекунду — раньше вы ставили специализированную базу. Сегодня расширение TimescaleDB превращает Postgres в мощнейший инструмент для работы с временными рядами, который автоматически оптимизирует хранение старых данных на диске.
- Взлет эпохи ИИ (pgvector). С бумом нейросетей всем резко понадобилось хранить так называемые векторные эмбеддинги (это то, как ИИ «понимает» тексты или картинки в виде набора цифр). Появились десятки новых векторных баз. Но сообщество Postgres быстро выпустило плагин pgvector. И теперь прямо внутри вашей основной базы можно делать умный семантический поиск для нейросетей.
- Геоданные (PostGIS). Это вообще золотой стандарт индустрии. Если вы строите сервис доставки или такси, лучшего инструмента для работы с картами, координатами и полигонами, чем это расширение для Postgres, в мире просто не существует.
Главный закон архитектуры: меньше сущностей — меньше проблем
Почему бизнес и опытные синьоры так любят Postgres? Потому что в реальном продакшене каждый новый элемент инфраструктуры — это огромная головная боль.
Если у вас в проекте для таблиц стоит Postgres, для логов — одна NoSQL база, для поиска — другая, а для векторов — третья, то ваш DevOps-инженер превращается в круглосуточного пожарного. Каждую базу нужно обновлять, бэкапить, настраивать права доступа, следить, чтобы между ними не рассинхронизировались данные, и платить за отдельные сервера.
PostgreSQL позволяет любому стартапу на этапе роста закрыть 95% всех потребностей бизнеса с помощью одной-единственной технологии. У вас одна база, один процесс бэкапа, одна понятная зона ответственности. Вы экономите деньги компании и нервы разработчиков.
Какой итог?
NoSQL не умер окончательно — специализированные решения вроде Redis до сих пор незаменимы для быстрого кэширования в оперативной памяти, а огромные корпорации используют специфические базы для специфических задач.
Но как универсальное решение для большинства ИТ-проектов NoSQL войну проиграл. PostgreSQL доказал, что здоровая консервативность, академическая надежность и умение вовремя адаптироваться под тренды бьют любой, даже самый громкий маркетинговый хайп. Начинаете новый проект? Не изобретайте велосипед, ставьте слона — он не подведет.
А вы помните времена, когда все фанатели от NoSQL? Приходилось ли вам вычищать MongoDB из проектов и возвращать всё на классические реляционные рельсы?
❤️ Поддержите автора Донатом — это лучший способ сказать спасибо всей команде IT Extra. Ваша поддержка очень вдохновляет нас на создание интересного и качественного контента!
👍 Ставьте лайки если хотите разбор других интересных тем.
👉 Подписывайся на IT Extra на Дзен чтобы не пропустить следующие статьи
Если вам интересно копать глубже, разбирать реальные кейсы и получать знания, которых нет в открытом доступе — вам в IT Extra Premium. Это — ваш личный доступ к экспертизе, упакованной в понятный формат. Не просто теория, а инструменты для роста.
👉 Переходите на Premium и начните читать то, о чем другие только догадываются.