В 2012 году все писали на Backbone.js. Это было современно. Это было правильно. Конференции, курсы, книги. «Если ты не знаешь Backbone — ты отстал».
В 2014 году пришёл Angular. Первый. Тот, который потом назовут AngularJS, чтобы отличать от того Angular, который его убил. Backbone стал легаси. Все переписывали на Angular. Это было современно. Это было правильно.
В 2015 году пришёл React. Angular стал «слишком сложным», «слишком enterprise», «слишком Google». Все переписывали на React. Это было современно. Это было правильно.
Сейчас уже поговаривают, что React — это новый jQuery. Слишком много boilerplate. Слишком много legacy-подходов. Есть же Svelte. Solid. Qwik. HTMX, в конце концов — назад к основам.
А знаешь, что было в 2012 году? PostgreSQL. Знаешь, что будет в 2030? PostgreSQL.
Фреймворки решают проблемы, которые сами же и создают. Каждый новый фреймворк — это ответ на недостатки предыдущего. Angular был ответом на хаос jQuery-спагетти. React был ответом на сложность Angular. Svelte — ответ на виртуальный DOM React.
Это бесконечная гонка. Каждые три-четыре года индустрия коллективно решает, что всё, что мы делали раньше — было неправильно. И теперь-то мы знаем, как надо. До следующего раза.
PostgreSQL не участвует в этой гонке. PostgreSQL просто работает. Версия 7.0 вышла в 2000 году. Версия 17 — в 2024. За эти годы добавились JSON, полнотекстовый поиск, репликация, партиционирование. Но SELECT * FROM users WHERE id = 1 работает так же, как работал двадцать пять лет назад.
Есть такое понятие — Lindy effect. Чем дольше что-то существует, тем дольше оно проживёт. Книга, которая издаётся сто лет, скорее всего будет издаваться ещё сто. Технология, которая работает тридцать лет, скорее всего проработает ещё тридцать.
PostgreSQL — 1996 год. Двадцать девять лет.
MySQL — 1995 год. Тридцать лет.
SQLite — 2000 год. Двадцать пять лет.
React — 2013 год. Двенадцать лет.
Vue — 2014 год. Одиннадцать лет.
Svelte — 2016 год. Девять лет.
Кто из этого списка будет актуален в 2045 году? Я ставлю на базы данных.
Почему так? Потому что базы данных решают фундаментальную проблему. Хранить данные и доставать их обратно. Эта проблема не меняется. Она была в 1970 году, когда Кодд придумал реляционную модель. Она будет в 2070 году.
Фреймворки решают проблему «как удобнее писать UI». Это важная проблема, но она не фундаментальная. Она зависит от моды. От вкусов. От того, что считается «чистым кодом» в этом сезоне. Компонентный подход сегодня — очевидность. Двадцать лет назад — радикальная идея. Через двадцать лет — возможно, устаревший подход.
SQL пережил объектные базы данных. Пережил XML-базы. Пережил NoSQL-революцию. Пережил GraphQL. Каждый раз кто-то объявлял, что SQL мёртв. И каждый раз SQL отвечал: «Окей, я добавлю JSONB, и вы продолжите меня использовать».
Я видел проекты, где переписывали фронтенд три раза за пять лет. jQuery → Angular → React. Каждый раз — месяцы работы. Каждый раз — «теперь-то будет правильно». Каждый раз — через два года новый CTO говорил, что это легаси.
База данных при этом оставалась той же. PostgreSQL. Те же таблицы. Те же индексы. Те же запросы. Фронтенды приходили и уходили. Данные оставались.
Данные — это единственное, что реально имеет ценность. Код можно переписать. Инфраструктуру можно перестроить. Данные переписать нельзя. Поэтому база данных — это не просто технический выбор. Это фундамент, на котором всё стоит.
Когда ты выбираешь фреймворк, ты выбираешь набор компромиссов, актуальных сегодня. Команда, которая его написала, решала свои проблемы. Facebook сделал React для Facebook. Google сделал Angular для Google. Их проблемы — не твои проблемы.
Когда ты выбираешь PostgreSQL, ты выбираешь сорок лет коллективной мудрости. Тысячи edge cases, которые уже обработаны. Миллионы часов production-нагрузки. Документацию, которую писали люди, понимающие, что документация — это часть продукта.
Попробуй найти ответ на сложный вопрос о своём любимом фреймворке. Stack Overflow, GitHub Issues, Discord-чаты. Половина ответов устарела, потому что это было в предыдущей мажорной версии.
Теперь попробуй найти ответ о PostgreSQL. Официальная документация. Исчерпывающая. Актуальная. С примерами. Написанная так, будто авторы уважают твоё время.
Я не говорю, что не нужно учить фреймворки. Нужно. Ты не напишешь современный фронтенд без чего-то. Но относиться к этому стоит как к расходному материалу. Инструмент на три-пять лет. Потом будет другой.
А вот в базы данных стоит инвестировать глубоко. Понимать, как работают индексы. Что делает планировщик запросов. Как устроена репликация. Почему VACUUM — это важно. Эти знания не устареют. Они будут работать на тебя десятилетиями.
Я знаю людей, которые могут наизусть рассказать API React, но не понимают, что такое EXPLAIN ANALYZE. Это как знать все функции микроволновки, но не понимать, как работает огонь.
Есть карго-культ новизны. Новое — значит лучше. Если технологии больше пяти лет — она устарела. Если ты не переписал проект на последний фреймворк — ты отстал.
Это выгодно тем, кто продаёт курсы. Выгодно конференциям. Выгодно консультантам. Каждый новый хайп — это новые курсы, новые книги, новые выступления.
Это невыгодно тем, кто строит продукты. Потому что каждая миграция — это время, которое можно было потратить на фичи. Это баги, которых не было бы, если бы не трогали работающий код. Это знания, которые обесцениваются через три года.
Boring technology выигрывает. Не потому что она лучше. А потому что она предсказуема. Ты знаешь, как она сломается. Ты знаешь, как её чинить. Ты знаешь, что она будет работать завтра.
В 2015 году MongoDB была будущим. Веб-масштаб. Схема не нужна. JSON everywhere. Все переходили на Mongo, потому что SQL — это прошлый век.
В 2024 году MongoDB добавила транзакции, схемы, и вообще стала подозрительно похожа на реляционную базу. А PostgreSQL добавил JSONB и стал лучшей документной базой, чем Mongo. Потому что ты можешь хранить JSON и при этом иметь транзакции, индексы и JOIN-ы.
Это типичный паттерн. Новая технология обещает революцию. Потом выясняется, что старые проблемы никуда не делись. Новая технология начинает решать старые проблемы. В итоге она становится похожа на то, что заменяла. Только с худшей документацией и меньшим комьюнити.
Совет джуну: когда выбираешь, что учить глубоко — выбирай то, что будет актуально через десять лет. SQL. HTTP. Unix. Алгоритмы. Сети. Это фундамент. Это не изменится.
Фреймворки учи на уровне «могу решать задачи». Не привязывайся. Не строй идентичность вокруг технологии. «Я React-разработчик» — это как «Я разработчик на Backbone». Звучало гордо в 2012. Звучит грустно в 2024.
«Я разработчик, который понимает базы данных» — это будет актуально всегда.
PostgreSQL был здесь до тебя. PostgreSQL будет здесь после. Твой любимый фреймворк — гость на этом празднике. Относись к нему соответственно.