​​Читаю книгу Мартина Клеппмана "Высоконагруженные приложения. Программирование, масштабирование, поддержка" и решил поделится интересными выводами, которые лично у меня структурировали знания о том, как и в какой ситуации выбирать СУБД для проекта или задачи.

Если модель данных подразумевает небольшое количество связей один-ко-многим (или большое, но логика приложения подразумевает, что документ загружается сразу, без или с минимальным количеством дополнительных запросов) - можно рассмотреть документоориентированные СУБД, где на хайпе до сих пор MongoDB. Ключевое слово тут - небольшое, потому что Mongo будет дублировать данные, из-за чего база будет денормализованной. Например, храним мы документы с пользователями, где к каждому пользователю опционально привязаны машины, которыми он пользуется, если они у него есть. Маловероятно, что у пользователя может быть большое количество машин, поэтому сохранить машины в документе, обернув их в json - может быть неплохой идеей. Дублировать нам придётся машины, потому что ссылаться на тачку, которая добавлена где-то в другом документе мы не можем так же, как можем это делать в реляционных базах, только искусственно. Если модель данных в принципе не подразумевает связей один-ко-многим, то документы - отличный выбор.
Тем не менее, развитие NoSQL породило множество СУБД, некоторые из которых, например, пытаются решить проблему ссылок и тем самым показать, что их можно использовать для большого количества связей один-ко-многим, например - RethinkDB и некоторые драйверы для MongoDB.

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

Если же проект подразумевает большое количество связей многие-ко-многим - стоит посмотреть в сторону графовых баз данных, потому что большое количество связей хорошо ложится на графовую модель. Реляционная база тоже позволит хранить такие данные, но работать с ними будет гораздо сложнее, и в книге приводятся несколько сравнений запросов для одной и той же схемы данных в графовом представлении и в реляционном: запрос, занимающий 2-3 строчки в графовой модели может занять 20-25 в реляционной.

Конечно, это очень общее и поверхностное описание, и стоит учитывать множество других моментов, например важен ли контроль схемы данных на стороне СУБД, как часто будут меняться данные, какой объём данных обрабатывается и как. Но в общем и целом, как первичные маркеры для выбора - подходит.