Почему MongoDB — наша основная база данных (И почему она должна быть вашей, если вы единственный основатель)

Я создал QuotyAI, потому что устал от AI, который гадает, медленных ответов на иностранных языках и инструментов, которые не выполняют обещаний. Вам нужна система, которая работает именно так, как задумано — каждый раз.

Когда вы создаёте AI, который пишет продакшн-код из естественного языка, выбор базы данных перестаёт быть предпочтением. Он становится ключевой частью надёжности вашего продукта.

Это не пост о том, что «MongoDB идеальна». Это вскрытие решения, компромиссов, сюрпризов и почему MongoDB был единственным жизнеспособным выбором для создания этого продукта в одиночку.

«Лучшая база данных — это та, о существовании которой вы забываете.»

Матрица решений

Я рассматривал три варианта:

PostgreSQL: безопасный выбор по умолчанию с JOIN-запросами, транзакциями и ограничениями.
SurrealDB: более новая база данных с графовыми запросами, опциональной схемой и встроенной аутентификацией.
MongoDB: противоречивая документная база данных, часто критикуемая за проблемы с масштабированием.

Я почти выбрал PostgreSQL. Пока я выбирал базу данных, я также разбирался с инфраструктурой — вы можете почитать о $30/месяц продакшн-стеке и почему я выбрал Bun и Hono для бэкенда.

PostgreSQL — отличная база данных. Если бы у меня была команда из 10 инженеров и фиксированная схема, я бы выбрал её не раздумывая. Я построил на ней первоначальный прототип, но быстро столкнулся с проблемой.

Вся ценность QuotyAI в том, что вы можете написать «комнаты по $50/ночь,$ 20 за уборку, скидка 10% при аренде от 7 ночей», и она генерирует этот код:

function calculatePrice(nights: number): number {
  const base = nights * 50;
  const cleaning = 20;
  const discount = nights >= 7 ? 0.1 : 0;
  return (base + cleaning) * (1 - -discount);
}

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

В PostgreSQL это требовало постоянных миграций ALTER TABLE. Для единственного основателя, решающего продакшн-проблемы в 3 часа ночи при ненадёжном интернете, это было невыносимо.

💡 Инсайт 1: Большинство сравнений баз данных измеряют неправильные метрики. Для единственных основателей когнитивная нагрузка и риск миграции важнее в 10 раз, чем чистая производительность запросов или теоретическое ACID-соответствие. Этот же принцип применяется к детерминированной AI-архитектуре — надёжность важнее эффектности, каждый раз.

Вот критерии, которые я использовал, в порядке приоритета:

Должна обслуживаться одним человеком. Никаких дежурств. Никакой паники от миграций в 3 ночи.
Должна обрабатывать полностью динамические схемы для каждого арендатора.
Должна позволять быстро итерироваться. Мне нужно выпустить фичу за час, а не за неделю.
Должна эффективно обрабатывать вложенные документы.

PostgreSQL провалил пункты 1 и 2. SurrealDB провалил неписанное пятое правило: я не могу быть первым человеком, отлаживающим продакшн-проблему.

SurrealDB технически впечатляет: JOIN-запросы, транзакции, графовые запросы, опциональная схема и нативные очереди. Особенно привлекала функция очередей для моего случая использования. Однако у неё было 1200 открытых GitHub-issues, доступный хостинг отсутствовал, жесткая политика egress-тарифов и слабая поддержка сообщества для отладки продакшн-проблем.

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

PostgreSQL провалил пункты 1 и 2. SurrealDB провалил по риску. MongoDB прошла все четыре.

Это не аргумент, что MongoDB универсально лучше — это был единственный жизнеспособный выбор для моих конкретных ограничений: создание AI-инструмента с произвольными схемами на арендатора в одиночку.

Для банковских систем, социальных сетей или команд с инженерными ресурсами другие базы данных будут лучшим выбором.

Глубокое погружение в реализацию

Это не теория. Это то, что мы реально отправляем в продакшн.

💡 Инсайт 2: Документная модель — это не только для неструктурированных данных — это для случаев, когда сама структура является продуктом.

Динамические бизнес-сущности

В этом суть. Взгляните на наш интерфейс BusinessEntity:

export interface BusinessEntity {
  _id: ObjectId;
  tenantId: string;
  name: string;
  industries?: Industry[];
  currency?: Currency;
  timezone?: string;
  inputFieldValues?: Record<InputField, unknown>;
  salesAssistantQuickConfig?: SalesAssistantQuickConfig;
  // ... ещё 12 опциональных полей
}

Каждое поле после name является опциональным.

Когда клиент описывает свои бизнес-правила, AI напрямую добавляет необходимые поля в документ бизнес-сущности вместе со сгенерированными типами, валидацией и функциями ценообразования. В MongoDB это не требует миграций или простоя.

Я изменял схему BusinessEntity 47 раз за первые три месяца. С PostgreSQL я бы потратил больше времени на написание миграций, чем на создание продукта.

Исполняемый источник AI

Вот где документная модель действительно сияет. Взгляните на этот интерфейс:

export interface AiExecutableSource {
  offeringsJsonSchema?: string;
  offeringsTsSchema?: string;
  orderJsonSchema?: string;
  dereferencedOrderJsonSchema?: string;
  orderTsSchema?: string;
  pricingFormula?: string;
  schedulingTransformationFunction?: string;
  orderValidationFunction?: string;
}

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

Этот подход устраняет JOIN-запросы и обращения к базе данных, обеспечивая время отклика в 50 мс и надёжное выполнение. При ответе на запросы клиентов мы загружаем один документ и получаем всё необходимое для генерации точного ответа.

Что я думал, что будет сложным, но оказалось лёгким

Транзакции: Все говорят, что транзакции MongoDB сломаны. Это не так. Они работают точно как заявлено, и мы используем их для каждой критической операции. Документация по транзакциям MongoDB исчерпывающая и точная.
Валидация документов: Вы можете применять валидацию схемы выборочно в MongoDB. Мы валидируем основные поля при записи, позволяя AI добавлять динамические поля без ограничений.

Что я думал, что будет лёгким, но стало 3-дневным кошмаром

Обновления во вложенных массивах: Синтаксис обновления для конкретных индексов массива — это тёмный лес с бесполезными сообщениями об ошибках. Я потратил три дня на отладку одной операции, которая должна была занять 10 минут.
Индексирование: MongoDB позволит вам создавать ресурсоёмкие индексы без предупреждения, что приводит к серьёзному падению производительности, на диагностику которого уходят дни.

Матрица решений, сравнивающая MongoDB, PostgreSQL и SurrealDB по поддерживаемости, поддержке динамических схем, скорости итерации и зрелости в продакшне

Цена входа

У каждого технического решения есть своя цена. Вот что мы платим за выбор MongoDB.

💡 Инсайт 3: Каждая база данных заставляет вас решать проблемы где-то. MongoDB переносит сложность из миграций в код приложения — и для единственных основателей это отличный обмен.

Без JOIN-запросов

Без JOIN-запросов вы учитесь денормализовать и дублировать данные. Мы храним названия компаний в 14 разных местах и должны обновлять их все при переименовании компании. Это немного раздражает, но за 8 месяцев продакшна у нас не было ни одного бага от денормализованных данных. Обмен того стоит.

Принудительное соблюдение схемы

Мы применяем большинство ограничений в коде приложения, а не на уровне базы данных. Это означает, что баги в приложении могут записывать неверные данные, но это случалось только дважды — оба раза исправлялось за 10 минут простым UPDATE-запросом. По сравнению с 47 изменениями схемы за первые три месяца — математика сходится.

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

Что я бы изменил, если бы начинал сначала

Если бы я начинал заново, я бы всё равно выбрал MongoDB, но я бы:

Реализовал валидацию схемы для основных полей раньше
Избегал вложенных массивов для элементов, требующих индивидуального обновления

Я продолжаю наблюдать за SurrealDB — её встроенные функции сообщений и очередей привлекательны, и я может вернусь к ней, когда она созреет.

Столбчатая диаграмма, сравнивающая частоту миграций схемы между MongoDB и PostgreSQL за 6 месяцев раннего развития стартапа

Вердикт

Как единственный основатель, ваше главное ограничение — не масштабируемость, а внимание. Вы можете отладить так много проблем или ответить на так много экстренных вызовов в 3 ночи, прежде чем выгорите.

MongoDB не мешает, позволяя вам сосредоточиться на создании продукта. Она не идеальна, и масштабирование до 10 миллионов пользователей потребовало бы работы, но она надёжно обрабатывает 1200 компаний и 10k одновременных разговоров. Я не трогал инфраструктуру базы данных уже 3 месяца.

Вот это победа.

«Вам не нужно идеальное решение — вам нужно правильное решение для ваших текущих ограничений.»

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

Если вы единственный основатель, создающий что-то с неструктурированными или динамическими данными, и вы цените скорость итерации над теоретической чистотой: не переусердствуйте. Используйте MongoDB. Вы всегда сможете переписать позже, если будете достаточно успешны, чтобы это потребовалось. Объедините это с $30/месяц инфраструктурным стеком и у вас будет продакшн-настройка, которая масштабируется без лишней суеты.

Часто задаваемые вопросы

Почему выбрать MongoDB единственному основателю?

MongoDB устраняет усталость от миграций благодаря динамическим схемам, не требует времени простоя для изменения схем и позволяет единственным основателям итерироваться в 10 раз быстрее, чем с традиционными реляционными базами данных. Она обрабатывает произвольные формы данных каждого арендатора без панических ALTER TABLE в 3 часа ночи. Бесплатный уровень MongoDB Atlas позволяет развернуть продакшн-инфраструктуру за 5 минут со встроенным мониторингом и резервным копированием.

Как насчёт транзакций и целостности данных?

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

Когда не стоит использовать MongoDB?

Избегайте MongoDB для банковских систем, социальных сетей со сложными JOIN-запросами или команд с выделенными инженерами по базам данных. Если у вас фиксированные схемы и более 10 инженеров, PostgreSQL послужит вам лучше.

MongoDB всё ещё актуален в 2026?

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