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

Почему люди просят LLM выбрать базу данных

Команды просят LLM посоветовать базу данных по той же причине, по которой просят их написать письмо или свести спецификации: это быстрее, чем начинать с нуля. Когда перед вами дюжина вариантов — PostgreSQL, DynamoDB, MongoDB, Elasticsearch, Redis, ClickHouse и другие — LLM быстро выдаёт шортлист, описывает компромиссы и даёт «достаточно хорошую» отправную точку для обсуждения в команде.

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

Что на самом деле означает «вывод на основе потребностей продукта»

Проще говоря: вы описываете продукт («маркетплейс с объявлениями и чатом»), данные («пользователи, заказы, сообщения») и ограничения («должно масштабироваться до 1M пользователей, нужен быстрый поиск, низкие операционные затраты»). LLM затем сопоставляет эти потребности с типичными архитектурными паттернами:

• реляционные данные → SQL
• гибкие документы → документное хранилище
• аналитика → колонно-хранилище/warehouse
• кэширование → key-value store
• полнотекстовый поиск → поисковый движок

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

Совет vs окончательное архитектурное решение

Рекомендацию LLM лучше рассматривать как гипотезу, а не приговор к архитектуре. Она может помочь вам:

• сформулировать ключевые вопросы, на которые нужно ответить
• выявить очевидные несоответствия на раннем этапе
• набросать меморандум для принятия решения, который вы доработаете с командой

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

Что может пойти не так (и как снизить риск)

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

Остальная часть статьи разбирает эти режимы отказа и заканчивается практическим чеклистом для валидации рекомендаций LLM по базе данных перед тем, как вы выберете стек.

Как LLM превращает требования в выбор базы данных

Когда вы просите LLM «посоветовать базу данных», он не оценивает СУБД так, как это сделал бы инженер. Модель конвертирует ваш запрос в выведенные требования, сопоставляет их с паттернами, которые видел ранее, и затем выдаёт ответ, который читался бы как решение.

Что модель считает входными данными

На вход идут не только явные детали, которые вы указываете (трафик, размер данных, требования к согласованности). Модель также использует:

• формулировку и структуру вашего запроса (что вы подчёркиваете, что опускаете)
• описание продукта (она сопоставляет «чат», «аналитику», «платежи», «IoT» и т. п. с типичными архитектурами)
• заявленные ограничения (провайдер облака, бюджет, навыки команды, дедлайны)
• выученные из обучающих данных «паттерны прошлого» (распространённые стеки, популярные блоги, частые пары)

Поскольку многие запросы неполные, модель часто заполняет пробелы неявными предположениями — иногда верно, иногда нет.

Что она выдаёт в ответ

Большинство ответов укладывается в три слоя:

1. выбор категории (SQL vs NoSQL; реляционная vs документная vs key-value)
2. конкретные движки (PostgreSQL, MySQL, DynamoDB, MongoDB, BigQuery, Redis)
3. набор «лучших практик» (индексы, кэширование, реплики для чтения, шардинг, event sourcing)

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

Почему это может звучать уверенно, хотя не быть уверенным

LLM обобщают по примерам; они не прогоняют ваш рабочий поток, не анализируют вашу схему и не бенчмарктят запросы. Если в тренировочных данных сильно ассоциируется «высокая нагрузка» с «NoSQL», вы можете получить такой ответ, даже если хорошо настроенная SQL-система подошла бы лучше.

Уверенная формулировка — это стиль, а не измерение. Если модель явно не перечисляет предположения («я предполагаю в основном append-only записи и допустима eventual consistency»), уверенность может скрывать реальную неопределённость: недостающие входные данные и непроверенные утверждения о производительности.

Что включает в себя «потребность продукта» на самом деле

Когда говорят «выбрать базу по потребностям продукта», чаще всего имеют в виду гораздо больше, чем «мы храним пользователей и заказы». Хороший выбор базы отражает то, что продукт делает, как он должен себя вести под нагрузкой и что ваша команда реально сможет поддерживать.

Функциональные потребности (что вы строите)

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

Нужны ли вам ad-hoc фильтрация и отчёты по многим атрибутам? Полагаться на join’ы между сущностями? В основном читать одну запись по ID или сканировать временные диапазоны? Эти детали определяют, подойдёт ли больше SQL-таблицы, документная модель, wide-column паттерны или поисковые индексы.

Нефункциональные требования (как система должна себя вести)

База выбирается не только по фичам, но и по ограничениям:

• целевые задержки (p95/p99) для ключевых действий пользователя
• требования по доступности и восстановлению (какое время простоя допустимо?)
• соотношение чтений/записей и пики нагрузки
• темп роста объёма данных и трафика на горизонте 6–24 месяцев

Система, которая может терпеть задержки в несколько секунд, сильно отличается от той, что должна подтверждать платёж за <200 мс.

Операционные потребности (что вы можете эксплуатировать)

Даже «идеальная» модель данных провалится, если операция не вписывается:

• резервные копии и тесты восстановления
• миграции и эволюция схемы
• нагрузка на дежурство и штат (опыт DBA vs универсальные инженеры)
• ограничения поставщика: квоты управляемого сервиса, поддержка регионов, окна обслуживания

Регуляторные требования (что вы обязаны доказать)

Требования соответствия могут быстро сузить выбор:

• гарантии хранения и удаления данных
• аудит (кто и когда менял запись)
• контроль доступа, шифрование и разделение обязанностей

LLM часто делает выводы о таких требованиях по расплывчатым подсказкам — поэтому явное указание здесь отличает полезный совет от уверенной ошибки.

Где рассуждение LLM может уклониться от реальности

LLM часто сопоставляют несколько заявленных потребностей («реальное время», «масштаб», «гибкая схема») с знакомой категорией («используйте NoSQL», «используйте Postgres»). Это полезно для генерации идей, но рассуждение уходит в сторону, когда модель начинает приравнивать функции базы данных к требованиям продукта.

Фичи ≠ потребности продукта

Список фич (транзакции, JSON-поддержка, полнотекстовый поиск, шардинг) звучит конкретно, но потребности продукта обычно описывают результаты: допустимая задержка, правила корректности, аудитируемость, навыки команды, ограничения миграции и бюджет.

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

Чеклисты пропускают форму данных и запросов

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

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

• ad-hoc аналитика по многим измерениям
• линейки событий пользователя с строгим порядком
• кросс-сущностные ограничения (например, запас не может упасть ниже нуля)

Производительность — это деталь реализации, а не обещание

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

Операционная пригодность может перевесить сырую возможность

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

LLM, как правило, недооценивают эти реалии, если вы явно не предоставите их.

Режим отказа 1: Обобщение по популярным правилам

LLM часто отвечают на вопросы о базах, опираясь на широко тиражируемые «правила», вроде «NoSQL лучше масштабируется» или «Postgres может всё». Эти упрощения звучат уверенно, но сглаживают сложную реальность продукта: что вы храните, как вы это запрашиваете и что происходит, когда всё идёт не так.

Классический ярлык: «NoSQL для масштаба»

Распространённый паттерн — при упоминании роста, высокой нагрузки или «big data» предположить, что самым безопасным выбором будет NoSQL. Проблема в том, что «масштаб» редко бывает первой нерешённой проблемой. Многие приложения упираются из-за:

• отсутствия индексов или неэффективных запросов
• неограниченной ретенции данных
• плохой кэш-стратегии
• недостаточно выделенных ресурсов

В таких случаях смена базы не исправит корневую причину — она просто поменяет инструменты.

Что игнорируется: join’ы, транзакции и строгая корректность

Правила «по умолчанию» также замыливают требования, которые сильно влияют на выбор базы. LLM может рекомендовать документное хранилище, упуская, что вам нужны:

• многошаговые обновления, которые должны быть атомарными
• строгая корректность для балансов, инвентаря или бронирований (strong consistency)
• отчётные запросы, склеивающие данные по сущностям (сложные join’ы)

Эти требования не исключают NoSQL автоматически, но повышают планку: может понадобиться тщательный дизайн схемы, дополнительная логика приложения или иные компромиссы, чем те, что предполагал LLM.

Почему эта ошибка дорогая

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

Относитесь к «правилам» как к триггеру для вопросов, а не к ответу. Спросите, что именно вы масштабируете (чтения, записи, аналитику), что должно быть корректным и какие запросы неизбежны.

Режим отказа 2: Недостающие или неоднозначные входные данные

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

Ловушка «реального времени» и «высокой нагрузки»

Слова вроде «реальное время», «высокая нагрузка», «масштабируемый» или «enterprise-grade» не переводятся однозначно в конкретную базу. «Реальное время» может означать «обновления в течение 5 секунд» для дашборда или «<50 мс» для торговых тревог. «Высокая нагрузка» — это 200 RPS или 200,000?

Без жёстких чисел LLM может по умолчанию выбрать популярные эвристики (например, «NoSQL для масштаба», «Postgres — всё») даже когда реальные нужды указывают в другую сторону.

Какие числа меняют ответ

Если вы не даёте их, модель молча предполагает:

• QPS на чтение/запись (пик vs среднее)
• целевые p95/p99 задержки (и применимость к чтениям или записям)
• объём данных сейчас, темп роста, политика ретеншна
• размер объектов (широкие строки? большие блобы?) и кардинальность индексов

Скрытые шаблоны запросов, которые вы забыли упомянуть

Самые опасные упущения часто связаны с формой запросов:

• отчётность и аналитика (group-by, time-buckets)
• фильтрация/сортировка по множеству полей
• ad-hoc запросы для поддержки и отладки
• бэфиллы, репроцессинг и «покажи всё для пользователя X»

База, прекрасно подходящая для key-value доступа, будет терпеть бедствие, когда продукт внезапно потребует гибкой фильтрации и надёжной отчётности.

Практический приём: требуйте уточнений перед рекомендацией

Обращайтесь к выбору базы как к двушаговому взаимодействию: сначала соберите ограничения, затем давайте рекомендации. Хороший промпт (или внутренний чеклист) должен требовать цифр и примерных запросов, прежде чем называть движок.

Режим отказа 3: Несовпадение модели данных

Обычная ошибка LLM — рекомендовать категорию базы (SQL, документная, графовая, wide-column), не проверив, вписываются ли данные продукта в эту модель. В итоге выбирают хранилище, которое кажется подходящим, но противоречит структуре информации, которую нужно представлять.

Несовпадение начинается с отношений

LLM часто не уделяют внимания глубине и кардинальности связей: один-ко-многим vs многие-ко-многим, вложенное владение, общие сущности и как часто пользователи переходят между ними.

Документная база может казаться естественной для «профилей пользователей», но если продукт часто отвечает на кросс-сущностные вопросы — «все проекты, где роль любого участника изменилась за последние 7 дней» или «топ-20 тегов по всем командам с фильтром по статусу соответствия» — вы уже не просто берёте документ по ID, вы выполняете join’ы.

Когда joins часты, вы либо:

• симулируете join’ы в коде приложения (доп. запросы и сложность), либо
• сильно денормализуете (дублируете данные по документам)

Скрытая стоимость денормализации

Дублирование не бесплатно. Оно увеличивает амплификацию записей, усложняет поддержание консистентности при обновлениях, затрудняет аудит и может создать тонкие баги («какая копия — источник правды?»). LLM иногда рекомендуют денормализацию как будто это одноразовый дизайн-выбор, а не постоянная операционная нагрузка.

Санитарная проверка: кандидатная схема + ключевые запросы

Прежде чем принять рекомендацию LLM, проведите простой тест:

1. Набросайте кандидатную схему (таблицы/коллекции/узлы) с первичными ключами и критическими связями.
2. Запишите 5–10 «ключевых запросов», которые продукт должен поддерживать (фильтрация, сортировка, агрегация, кросс-сущностные lookup’ы).
3. Спросите: выражает ли эта база эти запросы естественно и эффективно, без героической денормализации или многошаговых join’ов на стороне приложения?

Если модель и запросы не совпадают — рекомендация шум, даже если звучит уверенно.

Режим отказа 4: Пробелы в транзакциях и согласованности

LLM часто рассматривают «согласованность» скорее как предпочтение, чем как жесткое требование продукта. Это ведёт к рекомендациям, которые выглядят разумно на бумаге («используйте масштабируемое NoSQL-хранилище»), но разваливаются, когда реальные пользовательские действия требуют атомарных многошаговых обновлений.

Разрыв атомарности: многошаговые обновления

Многие продуктовые сценарии — это не единичная запись, а несколько операций, которые должны либо все выполниться, либо ни одна.

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

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

Eventual consistency ≠ «пользователи потерпят задержку»

LLM иногда приравнивают eventual consistency к «интерфейс обновится позже». Вопрос в том, может ли бизнес-действие терпеть расхождение.

Конфликты бронирования показывают важность: два пользователя пытаются забронировать одно и то же время. Если система принимает оба и «разрешит позже», вы не улучшаете UX — вы создаёте проблемы поддержки и возвратов.

Операционные семантики: идемпотентность, повторы и exactly-once

Даже при базе, поддерживающей транзакции, вокруг рабочего процесса нужны чёткие семантики:

• идемпотентные ключи, чтобы двойной клик «оплатить» не снял деньги дважды;
• безопасные повторы, которые устойчивы к частичным сбоям и тайм-аутам;
• exactly-once-эффекты (или осознанная альтернатива «at-least-once + дедуп») для событий, вебхуков и фоновых задач.

Когда LLM игнорирует это, он может рекомендовать архитектуры, требующие экспертной распределённой работы, чтобы достичь «обычной» корректности продукта.

Режим отказа 5: Предположения о производительности без тестов

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

«Быстро» без контекста нагрузки

Если вы не уточнили, что должно быть быстрым — p99 для одиночных чтений, пакетная аналитика, пропускная способность записи или время до первого байта — LLM может по умолчанию выбрать популярные варианты.

Два продукта могут оба требовать «низкой задержки», но иметь противоположные шаблоны доступа: один — key-value lookup’ы, другой — поиск + фильтрация + сортировка по множеству полей.

Скрытые ограничения: индексы, амплификация и горячие партиции

Советы по производительности сбиваются, когда модели игнорируют:

• ограничения индексов и компромиссы: вторичные индексы ускоряют чтения, но замедляют записи и требуют места. У некоторых систем есть ограничения на составные индексы, время построения индекса или онлайн-изменения индексов.
• амплификация записи: движки на основе LSM могут превращать «простую запись» в значительную фоновую компактировку, что важно при постоянном приёме данных.
• горячие партиции: шардинг/партиционирование всё равно может забиться, если трафик концентрируется на узком диапазоне ключей.

Поведение кэша и форма запросов

LLM может предполагать, что кэши всё спасут, но кэши помогают только предсказуемым шаблонам доступа. Запросы, которые сканируют большие диапазоны, сортируют по неиндексированным полям или используют ad-hoc фильтры, не попадают в кэш и нагружают диск/CPU.

Малые изменения в форме запроса (например, пагинация через OFFSET vs keyset) могут перевернуть производительность.

Небольшой план бенчмарка (лучше, чем догадки)

Вместо доверия общим «X быстрее Y», запустите лёгкий, ориентированный на продукт тест:

1. Выберите 3–5 репрезентативных запросов (включая худшие кейсы фильтрации и сортировки) и 1–2 шаблона записи (стабильная + всплесковая).
2. Используйте реалистичный объём данных (по крайней мере, чтобы он превышал память; включите скошенность и горячие ключи).
3. Измерьте p50/p95/p99 задержки и пропускную способность отдельно для чтений и записей.
4. Протестируйте варианты индексов (без индекса, минимальные индексы, «идеальные» индексы) и зафиксируйте накладные расходы на запись.
5. Запустите с конкурентностью, близкой к ожидаемому пику, и следите за CPU, диском, компактировкой и метриками блокировок/транзакций.

Бенчмарки не предскажут всё, но быстро покажут, насколько предположения LLM по производительности соответствуют реальности.

Режим отказа 6: Операционные и стоимостные упущения

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

Скрытая работа: бэкапы, восстановление и миграция

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

LLM часто пропускают эти детали или предполагают, что они «встроены», не проверяя мелкий шрифт.

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

Наблюдаемость — часть продукта

Команды нужны не просто база, а то, как её оперировать.

Если рекомендация игнорирует slow query logs, метрики, дашборды, трассировку и алерты, вы можете не заметить проблемы, пока не начнут жаловаться пользователи. Инструменты эксплуатации сильно различаются между управлямыми и self-hosted решениями и между вендорами.

Полная стоимость — не только почасовая цена

LLM склонны недооценивать стоимость, фокусируясь на размере инстанса и забывая множители:

• рост хранения и политика ретеншна
• IOPS/ценообразование пропускной способности и лимиты всплесков
• реплики для чтения и высокой доступности
• время дежурства, реагирование на инциденты и планы поддержки вендора

Сопоставьте базу с командой

«Лучшая» база, которую команда не может уверенно поддерживать, редко оказывается лучшей. Рекомендации должны соответствовать навыкам команды, ожиданиям по поддержке и требованиям соответствия — иначе операционный риск станет доминирующей стоимостью.

Режим отказа 7: Чрезмерно сложные мульти-базовые дизайны

LLM иногда пытаются «решить всё сразу», предлагая стек вроде: Postgres для транзакций, Redis для кэширования, Elasticsearch для поиска, Kafka + ClickHouse для аналитики и графовую БД «на всякий случай». Это звучит впечатляюще, но часто такое преждевременное проектирование создаёт больше работы, чем ценности — особенно на ранних этапах продукта.

Почему совет идёт не так

Мульти-базовый дизайн кажется подстраховкой: каждый инструмент «лучше» для своей задачи. Скрытая стоимость в том, что каждая дополнительная БД добавляет деплой, мониторинг, бэкапы, миграции, контроль доступа и новый набор режимов отказа.

Команды тратят время на поддержку интеграций вместо доставки функциональности.

Когда полиглот-персистенция оправдана

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

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

Если вы не можете назвать конкретный запрос, целевой показатель задержки, ценовое ограничение или операционный риск, который обосновывает дробление, скорее всего это преждевременно.

Ловушки согласованности и дублирования между хранилищами

Как только данные живут в нескольких местах, появляются трудные вопросы: какое хранилище — источник правды? Как поддерживать согласованность при повторах, частичных ошибках и бэфиллах?

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

Практическое правило принятия решения

Начните с одной универсальной базы, которая покрывает ваши ключевые транзакции и отчётность. Добавляйте специализированное хранилище только после того, как вы (1) зафиксируете, что текущая система не справляется с требованием и (2) определите модель владения синхронизацией и восстановлением.

Держите возможность отхода, а не сложность.

Практический чеклист для валидации советов LLM по базе данных

LLM могут помочь с созданием первичного проекта рекомендации по базе данных, но относитесь к нему как к гипотезе. Используйте чеклист ниже, чтобы валидировать (или отклонить) предложение перед тем, как тратить ресурсы на реализацию.

1) Проясните входы (запишите их)

Преобразуйте промпт в явные требования. Если вы не можете его ясно описать, модель, скорее всего, догадывается.

• Какой основной рабочий режим продукта: OLTP, аналитика, поиск, временные ряды, messaging?
• Ожидаемый масштаб: пользователи, записи/сек, чтения/сек, рост хранения, пик/среднее.
• Нефункциональные потребности: uptime, мульти-регион, соответствие, бюджет, навыки команды.

2) Смоделируйте данные и ключевые запросы

Набросайте реальные сущности и связи (хотя бы эскиз). Затем перечислите топовые паттерны доступа.

• Какие 10 ведущих чтений и записей?
• Какие запросы должны быть быстрыми в пике?
• Что нужно индексировать, объединять, агрегировать или искать?

3) Определите acceptance tests (критерии успеха)

Переведите «быстро и надёжно» в измеряемые тесты.

• Цели по задержке и пропускной способности (p95/p99) для топ-запросов
• Требования к согласованности и транзакциям (что должно быть атомарно?)
• Кейсы отказа: потеря ноды, сетевые разделения, отказ региона, время backup/restore

4) Проведите лёгкий proof-of-concept

Используйте реалистичные формы данных и миксы запросов, а не игрушечные примеры. Загрузите репрезентативный набор данных, прогоните запросы под нагрузкой и измерьте.

Если LLM предложил несколько баз, протестируйте сначала самый простой однохранилищный вариант, а затем докажите, почему нужно дробить.

Если нужно ускорить этот шаг, практический подход — прототипировать тот кусок продукта, который определяет выбор базы (пара ключевых сущностей + ключевые эндпоинты + самые важные запросы). Платформы вроде Koder.ai могут помочь: вы описываете рабочий поток в чате, генерируете рабочее web/backend-приложение (часто React + Go + PostgreSQL) и быстро итеративно уточняете схему, индексы и форму запросов. Полезны функции планирования, снепшоты и откат при экспериментировании с моделями данных и миграциями.

5) Документируйте решение — и «триггеры для смены»

Напишите краткую мотивацию: почему эта база подходит под рабочую нагрузку, какие компромиссы вы принимаете и какие метрики заставят пересмотреть выбор позже (например, устойчивый рост записей, новые типы запросов, мульти-региональные требования, ценовые пороги).