A resposta do @maniero é completíssima!!!
Um caso de uso:
- Precisávamos guardar uma parte dos históricos de procedimentos industriais que não podiam ser alterados. Essa parte correspondia a um "questionário" e precisavam ser basicamente uma linha do tempo, um "commit", imutável, mesmo se futuramente o "questionátio" mudasse, na linha do tempo deveríamos ter a pergunta e a resposta do usuário naquele momento. Foi decidido então usar um banco não relacional pra isso, e que no final foi implementado no DynamoDB da AWS.
Só uma observação: noSQL significa not only SQL e não no SQL, porque bancos não relacionais podem ou não ter SQL, por isso o not only (não apenas) SQL.
Esse é um exemplo, tem vários outros. Mas são sempre casos mais específicos, não costuma ser bom para modelar uma aplicação inteira que fecha todos os aspectos de uma empresa. Nos links que eu passei tem uma listinha de exemplos.
O termo passou ser not only porque alguém notou que no não fazia sentido. No internado até hoje todo mundo escreve NoSQL e não NOSQL. Várias NoSQL usam SQL :D Por isso tiveram que mudar o significado. Tudo isso começou como uma enorme gambiarra, desde o termo. Aí tiveram que ajambrar.
Já é um enorme problema ter tantos modelos sendo chamados de NoSQL, isso causa entendimento errado. E para reforçar oque eu não deixei claro, o problema é o modelo de documento. Os outros modelos são bem menos usados e quase sempre adotam quando faz sentido e que o relacional não encaixa bem.
As pessoas abusam do modelo de documento (em alguns casos, mas bem mais raro, do chave-valor) e o adotam para algo que precisa de relacional. Provavelmente MongoDB tem um mercado 20 ou 30 vezes maior do que deveria ter.
De fato a moda trouxe umas coisas interessantes, tanto que os principais fornecedores de relacionais copiaram e colocaram essas novas features no relacional. Não é a mesma coisa, mas boa parte do que veio no modelo de documento dá para fazer no relacional, ao mesmo tempo.
Para usar todas as vantagens do modelo de documento, e a maioria dos usos reais dele não usam, por isso parece simples, realmente precisa de um produto dedicado, mas aí tem que abrir mão de algumas coisas que só o relacional consegue dar, e boa parte dos problemas existem e não podem abrir mão. E para conseguir as duas coisas é necessário praticamente reproduzir o banco de dados na aplicação, fazendo que perca a vantagem.
Então, novamente, tem casos que ele encaixa, e isso faz sentido, e tem muitos, mas ainda é uma minoria onde ele é bem útil. Que bom que inventaram, que ruim que a sociedade sempre abusa de novidades.
Um motivo extra para evitar é que o principal fornecedor mente muito, e influenciadores que falam dele fazem isso também. Quando precisa fazer isso já é um motivo político para se afastar.Se só falassem a verdade ele ainda seria adotado, mas não tanto quanto é.
Show maninho! Obrigado por complementar.