Как выбрать базу данных для сайта: пять вопросов до подключения сервиса

Выбор базы данных часто начинается с названий: PostgreSQL, MongoDB, Firebase, SQLite. Для нового сайта это неудобная точка старта. Один и тот же сервис может быть отличным для одного сценария и создавать лишние ограничения в другом.

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

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

Затем соедините сущности:

· один пользователь может иметь несколько заказов;

· один курс состоит из нескольких уроков;

· один заказ содержит одну или несколько позиций;

· специалист оказывает несколько услуг;

· свободный слот принадлежит конкретному специалисту.

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

Документная база может быть удобна, когда объект естественно хранится целиком и его поля сильно различаются. Но фраза «у нас JSON» не является достаточным аргументом. PostgreSQL тоже умеет хранить JSON, а выбор определяется не форматом ответа API, а операциями над данными.

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

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

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

Спросите:

· есть ли деньги, остатки, квоты или права доступа;

· возможны ли одновременные изменения одной записи;

· что произойдет при повторном запросе;

· какие дубликаты недопустимы;

· как система восстанавливается после ошибки между шагами.

Если ответ «мы потом почистим данные», риск уже заложен в архитектуру. ИИ может быстро написать код обновления, но не определит за владельца продукта, какое состояние считается допустимым.

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

Для сайта нарисуйте путь:

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

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

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

Не спрашивайте только «сколько стоит в месяц». Спросите:

· кто получит уведомление о заполненном диске;

· как обновляется версия базы;

· где хранятся резервные копии;

· кто проверяет восстановление;

· как выдается и отзывается доступ сотрудника;

· где посмотреть медленный или ошибочный запрос;

· что произойдет после превышения лимита тарифа.

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

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

Проведите небольшой тест выхода еще до запуска:

1. создайте несколько связанных записей и файл;

2. сделайте резервную копию или экспорт;

3. восстановите данные в отдельной среде;

4. сравните количество записей и связи;

5. проверьте, сохранились ли пользователи и права;

6. оцените, какие части нельзя перенести стандартными средствами.

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

Подходит для связанных данных, отчетов, транзакций и правил целостности. У него развитый SQL и большой выбор управляемых хостингов. Цена этой универсальности - необходимость продумать схему, миграции, индексы и права.

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

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

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

Соберите один вертикальный сценарий. Для сайта записи на консультацию это путь от выбора времени до подтверждения менеджером. Он должен включать:

· создание пользователя;

· запись связанных данных;

· две роли с разными правами;

· повторный запрос без дубля;

· одновременную попытку занять один слот;

· ошибку на середине операции;

· резервную копию и восстановление.

Не измеряйте скорость по пустой таблице. Внесите данные, похожие на реальные по объему и форме. Посмотрите не только время ответа, но и сложность кода, диагностики и восстановления.

Зафиксируйте выбор на одной странице:

· сущности и критичные связи;

· операции, которым нужны транзакции;

· роли и путь доступа;

· владелец эксплуатации;

· способ резервного копирования и восстановления;

· известные ограничения;

· условие пересмотра решения.

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

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

1. свойства самого движка базы;

2. условия управляемого сервиса и его интеграций.

Спросите, можно ли подключиться стандартным клиентом, выгрузить обычный dump, выбрать регион, создать read-only пользователя и посмотреть медленные запросы. Проверьте, входят ли файлы и пользователи платформы в резервную копию базы. Часто это отдельные хранилища с отдельным восстановлением.

Так вы не приписываете базе ограничения панели и не считаете переносимым весь backend только потому, что таблицы используют знакомый SQL.

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

Для каждой миграции проверьте:

· можно ли применить ее к копии рабочих данных;

· что произойдет со старыми строками;

· сколько времени займет блокировка;

· совместим ли старый код с переходным состоянием;

· есть ли путь отката или безопасного продолжения.

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

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

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

Не выбирайте распределенную базу ради абстрактного «масштаба». Ее операционная сложность может быть выше всего проекта. Условие масштабирования лучше записать наблюдаемой метрикой.

Восстановите не только таблицы. Поднимите отдельную среду, подключите приложение, создайте тестового пользователя, откройте файл и пройдите основной путь. Так обнаружится, что дамп не содержит storage, ключи потеряны или правила доступа не вернулись.

Замерьте фактическое время восстановления и допустимую потерю данных. Эти значения называются RTO и RPO, но названия менее важны, чем согласованное ожидание бизнеса: сколько продукт может быть недоступен и сколько последних изменений можно потерять.

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

Отдельные учетные данные упрощают отзыв и аудит. Секреты хранятся на сервере или в secret storage, а не в браузере и репозитории.

На курсе «Вайб-кодинг: быстрый старт» такой выбор можно пройти вместе с прототипом и проверками, не превращая список брендов в архитектуру.

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