MongoDB: NoSQL база данных для гибких данных без строгой схемы

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

Именно здесь на сцену выходит MongoDB. Это база данных, которая не требует заранее задавать все колонки. Она хранит каждую запись в виде отдельного документа — похожего на JSON-объект, — и позволяет разным записям иметь разный набор полей. Ниже — что такое MongoDB простыми словами, чем она отличается от уже знакомых PostgreSQL, Supabase и SQLite, когда она реально полезна вайбкодеру, а когда — ловушка, и как подключить её к проекту без глубоких знаний SQL.

Что такое MongoDB простыми словами

MongoDB — это NoSQL база данных. В переводе на человеческий язык: она не использует классические таблицы со строками и колонками. Вместо этого данные хранятся в документах. Каждый документ — это набор полей и значений, очень похожий на JSON, который ты видел в настройках приложений или в ответах API.

Представь обычную таблицу в Excel. У неё есть заголовки: имя, email, телефон, город. Если ты хочешь добавить для одного пользователя поле «любимый цвет», придётся добавить колонку для всех — и большинство ячеек останется пустой. В MongoDB каждый документ живёт сам по себе. Один пользователь может содержать имя, email и любимый цвет, другой — имя, email и список адресов доставки, третий — ещё что-то своё. Никаких пустых колонок, никакой общей решётки.

Такие документы объединяются в коллекции. Коллекция — это как папка с похожими документами: все они про пользователей, но каждый может быть немного уникальным. Внутри одной коллекции «товары» может лежать документ про смартфон с полями «экран», «процессор», «аккумулятор», и документ про футболку с полями «размер», «цвет», «состав ткани». MongoDB не возражает.

Эта гибкость делает MongoDB удобной для данных, которые сложно заранее уложить в одну таблицу. Особенно когда структура постоянно меняется, растёт или зависит от типа объекта. Вместо того чтобы проектировать сложную схему из десятка связанных таблиц, ты можешь начать с простых документов и добавлять поля по мере необходимости.

При этом MongoDB сохраняет мощные возможности для поиска. Можно искать документы по любым полям, сортировать, фильтровать, агрегировать данные, строить индексы для ускорения. Для вайбкодера это означает: можно просить ИИ-ассистента написать запрос на естественном языке, и он превратит его в код драйвера MongoDB — почти так же, как делает это для SQL.

Чем MongoDB отличается от PostgreSQL, Supabase и SQLite

В курсе мы уже разбирали реляционные базы данных: PostgreSQL, Supabase и SQLite. Они хранят данные в таблицах, где заранее определены колонки и типы данных. Этот подход называется SQL или реляционным. Подробнее про выбор базы данных для новичка можно почитать в статье «Базы данных для новичка».

В реляционной базе перед записью данных нужно создать таблицу и сказать: здесь будет текст, здесь число, здесь дата. Если позже понадобится новое поле, придётся менять структуру таблицы через миграцию. Миграция — это специальный скрипт, который говорит базе: «добавь колонку X». В небольшом проекте это не страшно, но по мере роста миграций их приходится отслеживать, проверять на тестовой копии и применять аккуратно, чтобы не сломать продакшен.

MongoDB работает иначе. Она не требует объявлять схему заранее. Ты просто вставляешь документ, и база его принимает. Хочешь добавить новое поле к одному документу — добавляй. Хочешь, чтобы у другого оно отсутствовало — пожалуйста. Это удобно на старте, когда ты ещё не знаешь окончательную структуру данных.

Но у этой свободы есть обратная сторона. В PostgreSQL база сама не даст тебе записать текст в числовую колонку или пропустить обязательное поле. В MongoDB таких встроенных ограничений нет по умолчанию. Если случайно в одном документе поле назвать email, а в другом emial, база промолчит. В результате в одной коллекции окажутся разные варианты, и поиск начнёт работать непредсказуемо. За порядком придётся следить самому или настраивать схему на уровне приложения.

Ещё одно важное отличие — связи между данными. В реляционных базах связи делаются через внешние ключи: таблица заказов ссылается на таблицу пользователей, таблица платежей — на таблицу заказов. Это надёжно и предсказуемо. MongoDB тоже умеет ссылки, но чаще данные встраивают прямо в документ. Например, заказ может содержать копию адреса доставки вместо ссылки на отдельную таблицу адресов. Это ускоряет чтение, но усложняет обновление: если адрес изменился, придётся обновлять его во всех заказах, где он встроен.

Supabase, который мы используем в курсе, построен на PostgreSQL и даёт дополнительный уровень безопасности через RLS-политики — Row Level Security. Они позволяют настроить правила: пользователь видит только свои записи, админ видит все. Это особенно важно для приложений с аккаунтами. Про RLS-политики мы подробно говорили в статье «RLS-политики в Supabase». У MongoDB нет точно такого же механизма из коробки, поэтому контроль доступа приходится реализовывать в приложении или на уровне облачного сервиса.

flowchart TB
    A["Пользователь открывает каталог"] --> B["SQL: сначала таблица товаров,<br>потом таблица характеристик"]
    A --> C["MongoDB: один документ<br>со всеми полями товара"]
    B --> D["Нужны JOIN и миграции<br>при новых полях"]
    C --> E["Добавляешь поле прямо<br>в нужный документ"]

Когда MongoDB действительно нужна вайбкодеру

MongoDB не заменяет реляционные базы данных, но решает свою узкую задачу. Вот ситуации, в которых она особенно удобна.

Каталог с разнородными товарами

Представь интернет-магазин, в котором продаются и смартфоны, и кроссовки, и книги. У смартфона важны диагональ экрана, оперативная память и ёмкость аккумулятора. У кроссовок — размер, цвет, материал подошвы. У книги — автор, издательство, количество страниц. В реляционной базе придётся либо делать общую таблицу с десятком пустых колонок, либо строить сложную систему отдельных таблиц для каждой категории и связывать их ключами.

В MongoDB достаточно одной коллекции «товары». Каждый товар — отдельный документ со своим набором полей. Смартфон хранит свои характеристики, кроссовки — свои, книга — свои. Приложение просто показывает те поля, которые есть. Добавить новую категорию «наушники» можно, просто начав вставлять документы с полями «тип крепления» и «время работы от батареи». Никаких миграций.

Логи событий

Когда приложение работает, оно постоянно генерирует события: пользователь нажал кнопку, завершил уровень, получил ошибку, открыл страницу. Эти события могут иметь разную структуру. Событие «уровень пройден» содержит счёт и время. Событие «ошибка» содержит код ошибки и стек вызова. Событие «покупка» содержит сумму и товары.

Хранить такие логи в реляционной таблице неудобно: на каждый тип события придётся либо делать отдельную таблицу, либо мириться с горой nullable-колонок. MongoDB принимает события такими, какие они есть. Потом можно быстро искать по типу, дате, пользователю и строить аналитику. Для игры «Змейка» это может быть полезно, если ты захочешь собирать статистику: какой уровень сложности выбирают чаще, как растёт средний счёт, где чаще всего проигрывают.

Контент с переменной структурой

Блог, CMS, страницы лендингов, уроки курса — весь этот контент часто меняется. Один пост состоит из заголовка и текста, другой добавляет видео, третий — галерею, четвёртый — блок с кодом или цитатой. В реляционной базе пришлось бы заранее описывать все возможные блоки. В MongoDB каждый пост — документ, внутри которого лежит массив блоков разных типов.

Быстрый прототип, где структура ещё неизвестна

На старте проекта ты часто не знаешь, какие поля понадобятся. Сегодня у заказа есть адрес и телефон, завтра добавляется комментарий курьеру, послезавтра — предпочтительное время доставки. С MongoDB можно не прерываться на миграции и сосредоточиться на функциональности. Правда, как только структура стабилизируется, имеет смысл навести порядок: одинаковые поля называть одинаково, убирать дубли, возможно, переносить связанные сущности в отдельные коллекции.

Интеграции с внешними API

Когда приложение получает данные от сторонних сервисов, их формат может меняться без предупреждения. Сегодня API возвращает поле user_id, завтра — userId, послезавтра добавляет новое вложенное объект. MongoDB легко принимает такие изменения, потому что не требует строгого соответствия схеме. Это снижает риск, что очередное обновление API сломает запись в базу.

Когда лучше остаться на PostgreSQL или Supabase

Несмотря на всю гибкость, MongoDB — не универсальное лекарство. Для многих типичных задач курса реляционные базы данных подходят лучше.

Пользователи, заказы и платежи

Классическая схема «пользователи → заказы → платежи → товары» отлично ложится на таблицы со связями. У каждого заказа есть один пользователь, у заказа может быть много позиций, каждая позиция ссылается на товар, платеж привязан к заказу. В PostgreSQL/Supabase такие связи делаются естественно и надёжно.

Если попытаться смоделировать ту же схему в MongoDB, можно быстро получить проблемы с целостностью данных. Например, если заказ встраивает копии товаров, а цена товара потом изменилась, в заказе останется старая цена — это хорошо для историчности, но плохо, если ты хотел актуальную. Если хранить ссылки на товары, то при чтении заказа придётся делать несколько запросов вместо одного JOIN.

Балансы и финансовые операции

Там, где важна точность и целостность, реляционные базы данных незаменимы. Баланс пользователя, история списаний, платежи — всё это требует транзакций. Транзакция гарантирует, что операция либо выполнится полностью, либо не выполнится вообще. Если деньги списались с одного счёта, они обязаны зачислиться на другой.

MongoDB тоже умеет транзакции, но они сложнее и требуют дополнительной настройки. В PostgreSQL транзакции — это базовая, привычная часть работы. Для финансов лучше не экспериментировать и выбирать проверенный инструмент.

Когда важны RLS-политики

Supabase предоставляет мощный механизм Row Level Security, который позволяет на уровне базы данных ограничить доступ пользователей к строкам таблицы. Например, пользователь видит только свои рекорды в общей таблице лидеров, а администратор — все. Это сильно упрощает разработку и снижает риск случайной утечки данных.

MongoDB не имеет прямого аналога RLS. Правила доступа придётся писать в коде сервера или настраивать в облачном Atlas, но это не так прозрачно, как в Supabase. Поэтому для приложений с пользовательскими аккаунтами, где важна безопасность, Supabase часто оказывается проще. Подробнее про разграничение доступа читай в «RLS-политики в Supabase».

Когда данные хорошо структурированы и редко меняются

Если твои сущности однородны и ты уже знаешь все поля наперёд, реляционная база даёт больше предсказуемости. Можно задать типы данных, ограничения, уникальные индексы, внешние ключи. База сама будет защищать тебя от глупых ошибок. MongoDB в таком случае не даёт особых преимуществ, а свобода без контроля может обернуться багами.

Как подключить MongoDB на практике

Для вайбкодера подключение базы данных обычно выглядит так: выбираешь облачный сервис, получаешь строку подключения и просишь ИИ-агента написать код, который читает и пишет данные. С MongoDB всё то же самое.

MongoDB Atlas

Самый популярный способ начать — облачный сервис MongoDB Atlas. У него есть бесплатный тариф, которого хватит для обучения, прототипов и небольших проектов. На бесплатном тарифе обычно доступно ограниченное количество ресурсов, но для первых шагов этого достаточно. Актуальные лимиты всегда можно посмотреть на сайте сервиса.

Процесс старта выглядит примерно так:

1. Регистрируешься в MongoDB Atlas.
2. Создаёшь новый кластер — это твоя база данных в облаке.
3. Настраиваешь доступ: создаёшь пользователя базы данных и разрешаешь подключения с твоего IP-адреса.
4. Получаешь connection string — специальную строку подключения, которая выглядит примерно как mongodb+srv://user:password@cluster...mongodb.net/.
5. Передаёшь эту строку в своё приложение и просишь Claude Code или другого ИИ-ассистента написать код для работы с коллекциями.

Работа через официальный драйвер

MongoDB предоставляет официальные драйверы для многих языков и платформ: Node.js, Python, Go, Java и других. Для веб-приложений, которые мы собираем на курсе, чаще всего используется драйвер для Node.js. Его можно установить через npm.

После установки в коде приложения создаётся клиент, который подключается к кластеру по строке подключения. Дальше можно выполнять операции: вставлять документы, находить их, обновлять, удалять. Всё это делается через методы, похожие на JavaScript-объекты. Запросы пишутся не на SQL, а в виде JSON-подобных структур.

Например, чтобы найти все товары категории «смартфоны», запрос может выглядеть так:

{ category: "смартфоны" }

А чтобы добавить новый товар:

{
  name: "Телефон X",
  category: "смартфоны",
  screen: 6.1,
  ram: 8,
  battery: 4000
}

ИИ-агент легко превращает такие запросы в код. Ты говоришь: «Добавь метод, который возвращает список товаров по категории», — и агент пишет нужную функцию с использованием драйвера MongoDB.

Что такое connection string

Connection string — это адрес базы данных в одной строке. В нём указано, где находится сервер, под каким пользователем подключаться и с какими параметрами. Этот адрес нужно хранить в секретах приложения, а не в открытом коде. Обычно его помещают в переменные окружения .env. Про хранение секретов можно почитать в статье «Что такое API» — там мы разбирали, как приложение общается с внешними сервисами и почему важно не светить ключи.

Примеры задач для ИИ-агента

Если ты хочешь добавить MongoDB в проект, можно дать агенту конкретные инструкции:

• Подключи MongoDB Atlas к проекту через переменную окружения MONGODB_URI.
• Создай коллекцию products и метод для добавления товара.
• Напиши функцию поиска товаров по категории и ценовому диапазону.
• Добавь индекс для ускорения поиска по полю category.
• Сделай метод для обновления полей товара по его идентификатору.

Чем конкретнее задача, тем лучше результат. Не проси агента «сделай всё с MongoDB» — лучше разбей на маленькие шаги.

Ограничения и подводные камни

MongoDB хороша, но у неё есть особенности, которые нужно понимать, чтобы не наступить на грабли.

Отсутствие строгой схемы по умолчанию

Свобода — это хорошо, но только пока в проекте работаешь ты один. Когда документов становится много, легко допустить опечатку в названии поля или забыть, что у одних записей поле называется price, а у других cost. Рано или поздно придётся вводить схему на уровне приложения — например, с помощью библиотек валидации — или использовать схему валидации MongoDB (validation rules).

Транзакции между документами сложнее

В PostgreSQL ты можешь обновить сразу несколько таблиц в одной транзакции, и если что-то пошло не так, все изменения откатятся. В MongoDB атомарные операции по умолчанию работают на уровне одного документа. Междокументные транзакции тоже возможны, но требуют дополнительной настройки сессий и не так привычны новичкам.

Раздувание документов

Поскольку в MongoDB принято встраивать связанные данные, документы могут разрастаться. Если в документ заказа встроить не только товары, но и всю историю общения с клиентом, профиль пользователя и логи доставки, со временем чтение такого документа станет медленным. Нужно следить за размером документов и выносить в отдельные коллекции то, что растёт независимо.

Индексы требуют внимания

Без индексов поиск по большим коллекциям будет медленным. В реляционных базах индексы — привычный инструмент, и ИИ-агенты часто добавляют их автоматически. В MongoDB тоже нужно думать, по каким полям чаще всего ищут. Проси агента добавлять индексы для частых фильтров.

Не везде есть бесплатные и удобные инструменты

PostgreSQL и Supabase окружены огромным количеством инструментов: ORM, админки, миграции, визуальные редакторы. У MongoDB тоже есть Compass — графический клиент для просмотра базы, — но экосистема немного другая. Если ты привык к табличному представлению, документы сначала могут показаться непривычными.

Честный вывод: стоит ли выбирать MongoDB

MongoDB — отличный инструмент для определённого класса задач. Она идеальна, когда данные разнородные, структура меняется, и тебе важна скорость прототипирования. Каталоги товаров с разными характеристиками, логи событий, контентные блоки, интеграции с меняющимися API — вот её естественная среда.

Для большинства же типичных проектов курса — пользователи, заказы, платежи, рекорды, таблицы лидеров — проще и безопаснее оставаться на PostgreSQL/Supabase. Там есть привычные таблицы, надёжные связи, транзакции и RLS-политики, которые мы разбирали в «RLS-политики в Supabase».

Поэтому MongoDB стоит рассматривать как дополнительный инструмент в арсенале, а не как замену реляционной базе. Если твой проект вырос из жёстких таблиц и начал требовать гибкости — попробуй MongoDB. Если же ты только начинаешь и данные хорошо ложатся в строки и колонки, лучше сначала освоить PostgreSQL через Supabase. Главное — не выбирать базу данных по красивому названию, а ориентироваться на задачу.

Как выглядит документ внутри

Если ты раньше видел JSON, документ MongoDB покажется знакомым. Вот пример документа, который мог бы храниться в коллекции products для интернет-магазина:

{
  "_id": "64c...",
  "name": "Беговые кроссовки Speed",
  "category": "обувь",
  "price": 7490,
  "currency": "RUB",
  "sizes": [40, 41, 42, 43, 44],
  "color": "чёрный",
  "material": {
    "upper": "сетка",
    "sole": "резина"
  },
  "inStock": true,
  "createdAt": "2026-08-15T10:00:00Z"
}

А вот документ из той же коллекции, но для смартфона:

{
  "_id": "64d...",
  "name": "Смартфон Nova 12",
  "category": "электроника",
  "price": 39990,
  "currency": "RUB",
  "screen": 6.5,
  "ram": 8,
  "storage": 256,
  "battery": 4800,
  "inStock": true,
  "createdAt": "2026-08-16T12:30:00Z"
}

Обрати внимание: у кроссовок есть массив размеров и вложенный объект material, у смартфона — свои поля. Оба документа лежат в одной коллекции products, и MongoDB не требует, чтобы у них был одинаковый набор полей.

Поле _id — это уникальный идентификатор документа. MongoDB добавляет его автоматически, если ты не указываешь свой. Оно нужно, чтобы отличать один документ от другого и обращаться к конкретной записи при обновлении или удалении.

Типы данных, которые понимает MongoDB

MongoDB поддерживает множество типов данных. Для вайбкодера важно знать основные:

• Строки — текстовые значения: имя, описание, email.
• Числа — целые и дробные: цена, количество, рейтинг.
• Булевы значения — true или false: флаг наличия товара, подтверждение email.
• Массивы — списки значений: теги, размеры, изображения.
• Вложенные объекты — объекты внутри объектов: адрес доставки, характеристики товара.
• Дата и время — для хранения моментов создания, обновления, событий.
• Null — отсутствие значения.

Этого набора хватает для подавляющего большинства задач. В одном документе могут сочетаться разные типы — это нормально.

MongoDB и «Змейка»

Учебный проект курса — браузерная игра «Змейка». Для неё MongoDB может пригодиться, если ты захочешь собирать детальную статистику игровых сессий. Например, каждое завершение игры можно сохранять как документ:

{
  "userId": "user_123",
  "score": 42,
  "level": 3,
  "durationSeconds": 145,
  "diedAt": "wall",
  "playedAt": "2026-08-20T18:10:00Z"
}

А в другом документе может быть другая структура — например, событие «открыл магазин скинов»:

{
  "userId": "user_123",
  "event": "shop_open",
  "skinsViewed": ["red", "neon", "gold"],
  "playedAt": "2026-08-20T18:15:00Z"
}

В реляционной базе для каждого типа события пришлось бы делать отдельную таблицу или добавлять множество пустых колонок. В MongoDB оба события спокойно живут в одной коллекции events, и ты можешь анализировать их вместе или по отдельности.

Важный нюанс: порядок полей не важен, а названия — очень важны

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

Поэтому полезно договориться с самого начала о правилах именования. Например, использовать «верблюжью» нотацию userId, createdAt, isActive — это общепринятый стиль в JavaScript и MongoDB. Или использовать змеиную нотацию user_id, created_at — главное, чтобы стиль был один.

Если работаешь с ИИ-агентом, можно дать ему инструкцию: «Во всех документах MongoDB используй поля в camelCase: userId, createdAt, updatedAt». Это сэкономит часы на потом.

Когда MongoDB стоит комбинировать с PostgreSQL

В реальных проектах часто используют не одну базу данных, а несколько. Например, пользователи, заказы и платежи хранятся в PostgreSQL/Supabase, где важны целостность и RLS-политики. А каталог товаров с разнородными характеристиками, логи событий или контент блога — в MongoDB.

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

Частые вопросы

MongoDB — это база данных для больших данных?

Не обязательно. MongoDB умеет работать с большими объёмами, но её главная особенность — не размер, а гибкость. Она удобна, когда данные разнородные и не укладываются в строгие таблицы. Для небольших проектов она тоже подходит, если структура данных подразумевает разные наборы полей.

Нужно ли знать SQL, чтобы работать с MongoDB?

Нет. MongoDB использует свой язык запросов, основанный на JSON-подобных структурах. Если ты знаком с JavaScript-объектами, освоить базовые операции будет несложно. ИИ-ассистент поможет превратить описание задачи на русском языке в рабочий код.

Можно ли использовать MongoDB вместо Supabase для проекта курса?

Технически можно, но для стандартных сценариев курса — аккаунты, таблица рекордов, заказы — Supabase проще и безопаснее из-за встроенных RLS-политик и привычной табличной модели. MongoDB имеет смысл, если появляется разнородный контент или каталог.

Что такое документ в MongoDB?

Документ — это запись в базе данных, представленная в формате, похожем на JSON. Он состоит из полей и значений. У разных документов в одной коллекции могут быть разные наборы полей.

Где хранить connection string от MongoDB?

Connection string — это секрет. Его нельзя публиковать в коде на GitHub. Храни его в переменных окружения, например в файле .env, который не попадает в репозиторий. На сервере значение переменной настраивается отдельно.

Может ли MongoDB потерять мои данные?

Как и любая база данных, MongoDB надёжна, если правильно настроить резервное копирование и репликацию. В облачном Atlas бэкапы обычно доступны как опция. Для важных проектов всегда настраивай регулярные бэкапы, независимо от выбранной базы.

Нужны ли миграции в MongoDB?

Строгих миграций не требуется, потому что схема не задана заранее. Но когда структура стабилизируется, полезно навести порядок: унифицировать названия полей, удалить дубликаты, вынести связанные сущности в отдельные коллекции. Это уже скорее рефакторинг, чем миграция в классическом смысле.