Когда NoSQL база может быть лучше реляционной?

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

Когда NoSQL выигрывает:

• документная (MongoDB) — данные естественно иерархичны и читаются целиком (профиль с настройками, карточка товара с вариантами), схема часто меняется;
• ключ-значение (Redis, DynamoDB) — доступ строго по ключу с предсказуемой задержкой на огромной нагрузке: сессии, корзины, кэш;
• wide-column (Cassandra, ScyllaDB) — огромный поток записи, данные по ключу партиции с сортировкой: сообщения, события, временные ряды;
• графовая — запросы по связям произвольной глубины (рекомендации, социальный граф);
• поисковая — полнотекстовый поиск и фасеты.

Цена: обычно нет произвольных JOIN, транзакции — в пределах документа или партиции, согласованность часто итоговая, модель данных проектируют под запросы и дублируют данные под разные запросы. Ответственность за целостность переходит к приложению.

На практике — основная реляционная база и специализированные хранилища рядом (поиск, кэш, аналитика), заполняемые через CDC или события.