Базы данных для бэкенда: PostgreSQL вглубь и карта хранилищ

Секция по базам данных на собеседовании — та, где разговор сходит с рельсов. Почему индекс не берётся. Что видит транзакция на Read Committed. Зачем в этом проекте Redis. Ответ пересказывает статью, и по следующему вопросу понятно, что он не засчитан.

Курс проходит эту территорию один раз и по порядку: от того, что такое таблица, до выбора набора хранилищ под конкретный сервис и защиты этого выбора.

Что у тебя будет в конце. Ты открываешь план медленного запроса и называешь причину, а не перебираешь индексы наугад. Объясняешь, как прошли две брони на один слот, хотя проверка в коде была, и каким механизмом это закрывается. Говоришь, почему рядом с PostgreSQL стоит Redis, а фотографии не лежат в таблице — с числами, а не со ссылкой на чужой блог. Осязаемого два: локальный стенд, на котором всё это проделано руками, и капстоун — решение по хранению для незнакомого сервиса, разложенное по ролям, с планом роста и трёхминутной защитой, которую можно произнести вслух.

Курс не питоновский — он вообще ничей. Предмет здесь данные, а не язык приложения. Запрос, схема, индекс и план читаются одинаково из Go, Java, TS, PHP, C# и Python; там, где без кода сервиса не обойтись — N+1, транзакция в коде, миграции, — он будет псевдокодом. Ни одного «как ты помнишь из своего фреймворка».

Это не курс про SELECT и JOIN. Планку видно по второй половине: MVCC и служебные колонки версий строки, уровни изоляции и аномалии, deadlock, устроенный своими руками, bloat и autovacuum, план на таблице в пять миллионов строк, построение индекса без блокировки записи, переезд схемы на живой базе, ANN-индекс и его точность.

Каждое следующее хранилище входит через ограничение, в которое ты упёрся сам. Не «глава про Redis», а «один и тот же запрос двадцать тысяч раз в минуту». Не «глава про S3», а «фотографии ресурсов не помещаются в базу». Сквозной проект — сервис бронирования ресурсов — растёт от восьми строк каталога до пяти миллионов броней; рядом живут камео-миры вроде маркетплейса на триста тысяч объявлений.

Дорога по темам: таблицы и первые запросы → JOIN, агрегаты, подзапросы → своя схема, изменения и транзакции → проектирование схемы, типы PostgreSQL и jsonb → оконные функции, CTE, LATERAL → индексы → планы запросов и диагностика → MVCC, изоляция, блокировки → схема на живой базе, партиционирование, реплики → полнотекстовый и векторный поиск → PostgreSQL как проект и другие SQL-СУБД → объектное хранилище → Redis → MongoDB → Elasticsearch → колоночная аналитика → выбор хранилища и капстоун.

Стек: PostgreSQL 18 и pgvector, SQL, Docker Compose, MinIO и S3 API, Redis, MongoDB, Elasticsearch, ClickHouse, DuckDB.

Границы честные. Эксплуатации здесь нет: настройка репликации и переключение, бэкапы и восстановление на точку во времени, пулер соединений, мониторинг, нагрузочное тестирование — не входят. Берётся только то, что меняет твой код и твою схему: наличие реплики и лаг чтения, партиционирование как дизайн, понимание пулинга. Нет API конкретных ORM — они разбираются как класс инструментов, без привязки к библиотеке. Нет распределённых систем: доставка изменений между сервисами, транзакционный исходящий ящик, сага остаются за границей. Нет дата-инженерии: пайплайны, витрины и моделирование аналитических хранилищ — другая профессия. Cassandra, графовые базы, временные ряды и Kafka разобраны обзорным уроком на глубину «на какой вопрос отвечает и где граница»; ставить по этому знанию систему в прод нельзя, и курс говорит об этом прямо.