Я создал QuotyAI, потому что устал от AI, который гадает, медленных ответов на иностранных языках и инструментов, которые не выполняют обещаний. Вам нужна система, которая работает именно так, как задумано — каждый раз.
Когда вы создаёте AI, который пишет продакшн-код из естественного языка, выбор базы данных перестаёт быть предпочтением. Он становится ключевой частью надёжности вашего продукта.
Это не пост о том, что «MongoDB идеальна». Это вскрытие решения, компромиссов, сюрпризов и почему MongoDB был единственным жизнеспособным выбором для создания этого продукта в одиночку.
«Лучшая база данных — это та, о существовании которой вы забываете.»
Матрица решений
Я рассматривал три варианта:
- PostgreSQL: безопасный выбор по умолчанию с JOIN-запросами, транзакциями и ограничениями.
- SurrealDB: более новая база данных с графовыми запросами, опциональной схемой и встроенной аутентификацией.
- MongoDB: противоречивая документная база данных, часто критикуемая за проблемы с масштабированием.
Я почти выбрал PostgreSQL.
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-соответствие.
Вот критерии, которые я использовал, в порядке приоритета:
- Должна обслуживаться одним человеком. Никаких дежурств. Никакой паники от миграций в 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>;
salesAssistantUserConfig?: SalesAssistantUserConfig;
// ... ещё 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.
💡 Инсайт 3: Каждая база данных заставляет вас решать проблемы где-то. MongoDB переносит сложность из миграций в код приложения — и для единственных основателей это отличный обмен.
Без JOIN-запросов
Без JOIN-запросов вы учитесь денормализовать и дублировать данные. Мы храним названия компаний в 14 разных местах и должны обновлять их все при переименовании компании. Это немного раздражает, но за 8 месяцев продакшна у нас не было ни одного бага от денормализованных данных. Обмен того стоит.
Принудительное соблюдение схемы
Мы применяем большинство ограничений в коде приложения, а не на уровне базы данных. Это означает, что баги в приложении могут записывать неверные данные, но это случалось только дважды — оба раза исправлялось за 10 минут простым UPDATE-запросом. По сравнению с 47 изменениями схемы за первые три месяца — математика сходится.
Руководство по валидации схемы MongoDB показывает, как можно получить лучшее из двух миров: гибкие динамические поля с валидацией критических данных.
Что я бы изменил, если бы начинал сначала
Если бы я начинал заново, я бы всё равно выбрал MongoDB, но я бы:
- Реализовал валидацию схемы для основных полей раньше
- Избегал вложенных массивов для элементов, требующих индивидуального обновления
Я продолжаю наблюдать за SurrealDB — её встроенные функции сообщений и очередей привлекательны, и я может вернусь к ней, когда она созреет.
Вердикт
Как единственный основатель, ваше главное ограничение — не масштабируемость, а внимание. Вы можете отладить так много проблем или ответить на так много экстренных вызовов в 3 ночи, прежде чем выгорите.
MongoDB не мешает, позволяя вам сосредоточиться на создании продукта. Она не идеальна, и масштабирование до 10 миллионов пользователей потребовало бы работы, но она надёжно обрабатывает 1200 компаний и 10k одновременных разговоров. Я не трогал инфраструктуру базы данных уже 3 месяца.
Вот это победа.
«Вам не нужно идеальное решение — вам нужно правильное решение для ваших текущих ограничений.»
Вам не нужно идеальное решение — вам нужно правильное решение для ваших текущих ограничений. MongoDB — не лучшая база данных для каждого случая использования, но она правильная для QuotyAI.
Если вы единственный основатель, создающий что-то с неструктурированными или динамическими данными, и вы цените скорость итерации над теоретической чистотой: не переусердствуйте. Используйте MongoDB. Вы всегда сможете переписать позже, если будете достаточно успешны, чтобы это потребовалось.
Часто задаваемые вопросы
Почему выбрать MongoDB единственному основателю?
MongoDB устраняет усталость от миграций благодаря динамическим схемам, не требует времени простоя для изменения схем и позволяет единственным основателям итерироваться в 10 раз быстрее, чем с традиционными реляционными базами данных. Она обрабатывает произвольные формы данных каждого арендатора без панических ALTER TABLE в 3 часа ночи. Бесплатный уровень MongoDB Atlas позволяет развернуть продакшн-инфраструктуру за 5 минут со встроенным мониторингом и резервным копированием.
Как насчёт транзакций и целостности данных?
Транзакции MongoDB работают точно как заявлено для критических операций. Вы можете применять проверку схемы выборочно для основных полей, позволяя AI добавлять динамические поля без ограничений. Для 99% случаев использования в стартапах этот баланс идеален.
Когда не стоит использовать MongoDB?
Избегайте MongoDB для банковских систем, социальных сетей со сложными JOIN-запросами или команд с выделенными инженерами по базам данных. Если у вас фиксированные схемы и более 10 инженеров, PostgreSQL послужит вам лучше.
MongoDB всё ещё актуален в 2026?
Безусловно. MongoDB обеспечивает продакшн-нагрузку в миллионах компаний по всему миру. Релиз MongoDB 7.0 включает значительные улучшения производительности, лучший оптимизатор запросов и расширенные функции безопасности.