Итоги и что дальше

В прошлом уроке мы спроектировали две схемы с нуля. На этом первая половина раздела закончена. Прежде чем идти вглубь, остановимся: соберём, что ты уже умеешь, честно сравним MongoDB с PostgreSQL и посмотрим на карту второй половины.

Привал на маршруте

В походе на привале не просто отдыхают. Сверяют карту: сколько прошли, где сейчас, какой участок впереди и хватит ли воды. Без привала легко пройти мимо развилки.

Этот урок такой привал. Новых команд в нём почти нет, зато есть ответ на вопрос, который тебе обязательно зададут на собеседовании и в команде: «а почему здесь MongoDB, а не Postgres?»

Что ты уже умеешь

За 23 урока ты прошёл путь от «что такое документ» до схемы под запросы приложения:

Кластер	Что умеешь
Введение	ставить MongoDB в Docker и Atlas, работать в mongosh, отличать базу, коллекцию и документ
CRUD: создание и чтение	вставлять документы, понимать ObjectId, искать с операторами, сортировать и листать страницы
CRUD: обновление и удаление	менять поля и массивы операторами, делать upsert, заменять и удалять документы
Моделирование данных	выбирать между встраиванием и ссылками, копировать данные осознанно, проверять документы схемой
Агрегация и индексы	считать отчёты конвейером, соединять коллекции через $lookup, создавать индексы и читать explain
Практика и экосистема	работать с базой из Node.js, понимать роль транзакций, реплик и шардов, проектировать схему

Если в какой-то строке чувствуешь неуверенность, вернись к урокам кластера до того, как идти дальше. Вторая половина опирается на первую целиком.

MongoDB или PostgreSQL

Ты прошёл и раздел про PostgreSQL, так что можешь сравнить их не по рекламе, а по опыту. Сначала честное наблюдение: граница размылась. MongoDB научилась транзакциям и валидации схемы, а PostgreSQL умеет хранить документы в JSONB с индексами. Выбор редко бывает «одно умеет, другое нет». Чаще вопрос в том, что из коробки удобнее для твоих данных.

	MongoDB	PostgreSQL
форма данных	документ с вложенными объектами и массивами	строки в таблицах, вложенное в JSONB
схема	гибкая, проверка по желанию через $jsonSchema	строгая, задаётся до записи
связи	встраивание и ссылки, $lookup для соединений	внешние ключи и JOIN, соединения дешёвые
целостность между документами	транзакции есть, но дороже обычных записей	транзакции на каждом шаге, ограничения целостности
масштаб на запись	шардирование встроено	один сервер на запись, шардирование через расширения и внешние решения
язык запросов	объекты JavaScript, конвейер агрегации	SQL, который знает почти каждый разработчик

Из таблицы следуют практические советы.

MongoDB хороша, когда данные сами складываются в документы: каталог товаров с разными свойствами у разных категорий, профили, контент, события. Когда главный запрос это «достать сущность целиком», а не «собрать отчёт из десяти таблиц». И когда заранее понятно, что данных будет так много, что понадобится шардирование.

PostgreSQL надёжнее, когда в данных много связей и правил целостности: деньги, бухгалтерия, бронирования, складской учёт. Когда отчёты строят по произвольным срезам, которые нельзя предсказать заранее. И когда команда сильнее в SQL.

Частый вариант это обе. Заказы и платежи в PostgreSQL, каталог и отзывы в MongoDB, кэш в Redis. Хорошая архитектура выбирает хранилище под задачу, а не одно на всё.

Чего стоит избегать: выбирать MongoDB со словами «не хочу думать о схеме». Схема в MongoDB есть всегда, только живёт она в коде приложения и в головах команды. Об этом были уроки про моделирование.