Вчера у меня снова спросили: «Какую базу данных выбрать для нашего стартапа?» И я поняла, что у меня нет нормального ответа на этот вопрос — только обрывки из документаций и сломанные продакшены. Решила разобраться раз и навсегда. Получился гайд, который мне самой не хватало три дня назад.
Почему этот вопрос вообще возникает
Когда проект — это один файл с кодом и тестовые данные, вам вообще не нужна база. Вы сохраняете JSON в файл, и всё работает. Проблемы начинаются, когда данных становится больше, пользователей — больше, а вам внезапно нужны одновременные запросы.
Типичная точка перелома: вы садитесь писать второй сервис, и вашему приложению вдруг нужно одновременно читать и писать данные, показывать их другим пользователям, фильтровать, сортировать. Вот тут и появляется вопрос выбора.
SQLite: ваш первый выбор, пока вы не доказали обратное
SQLite — это файл базы данных, который живёт прямо рядом с вашим кодом. Никакого сервера. Никакой настройки. Открыли файл — работает.
Плюсы:
- Ноль настройки. Скачали, подключили, работает.
- Невероятно быстрая запись. Потому что весь файл — локально, никакой сети.
- Идеально для микросервисов иedge-вычислений.
- Один файл = бэкап = одна команда
cp.
Минусы:
- Один writer за раз. Если у вас 100 одновременных пользователей, которые пишут — будет больно.
- Нет нормального масштабирования. Один файл не разложить по серверам.
- Типизация слабее, чем у PostgreSQL.
Когда выбирать: прототипы, малые проекты, мобильные приложения,edge-функции, любой проект до 100 тысяч активных пользователей.
PostgreSQL: когда данные — это серьёзно
PostgreSQL — это реляционная база с полноценным сервером. Она выдержит всё что угодно, если правильно настроить.
Плюсы:
- Полноценные foreign keys, transactions, triggers, stored procedures.
- Масштабируется горизонтально ( Patroni, Citus).
- JSON внутриPostgreSQL — можно хранить документы, если очень хочется.
- Невероятное количество расширений: PostGIS для геоданных, pgvector для эмбеддингов, TimescaleDB для time-series.
Минусы:
- Нужен сервер, настройка, бэкапы, мониторинг.
- Меньше производительность на простых операциях, чем SQLite.
- Кривая входа — настроить правильно непросто.
Когда выбирать: проекты с критичными данными, финансовые системы, проекты где нужны сложные связи между сущностями, любой проект который планирует рост больше 100 тысяч пользователей.
MongoDB: когда структура — это вред
MongoDB — документная база. Вы хранитеJSON-документы прямо в базе, без схемы.
Плюсы:
- Гибкость схемы. Добавление новых полей — без миграций.
- Отлично масштабируется горизонтально (шардирование).
- Natural JSON — вы храните то, что отдаёте клиенту.
- Aggregation pipeline для сложных запросов.
Минусы:
- Без схемы вы стреляете себе в ногу. Данные становятся неконсистентными.
- Transactions появились только в 4.0, и они медленнее реляционных.
- JOIN-ы работают через aggregation — больно.
Когда выбирать: каталоги с разными атрибутами, контент-платформы, проекты с меняющимся schema, real-time аналитика.
Матрица решений за пять минут
Вот простая схема, которую я теперь применяю:
Беру SQLite если: проект маленький, данных мало, я работаю одна или вдвоём, не нужна сложная аналитика, хочу минимум настройки.
Беру PostgreSQL если: у меня сложные связи между данными, нужны транзакции, я планирую серьёзный рост, у меня есть данные которые нельзя потерять.
Беру MongoDB если: структура данных заранее непонятна, я работаю с документами, у меня high-velocity запись, я могу жить без нормальных JOIN.
Что я выбрала для себя
Для kreativia.ru — SQLite. Потому что это один сервер, данные — мои, нагрузка — моя, и мне не нужны никакие особенности PostgreSQL. Когда (если) появится 100 активных пользователей в секунду — тогда и подумаю.
А вот для клиентского проекта с десятью сервисами и командой из пяти разработчиков — однозначно PostgreSQL. Схема, миграции, бэкапы,pgvector для поиска — всё это имеет смысл, когда вы не один.
Комментарии
Пока нет комментариев. Стань первым!