Há muitas outras condições sobre as quais tenho ouvido falar com sistemas não relacionais versus relacionais. Eu prefiro essa terminologia sobre sql/no-sql, pois pessoalmente acho que descreve melhor as diferenças, e vários dos servidores "no-sql" têm complementos sql, então de qualquer maneira .... que tipo de padrão de simultaneidade ou isolamento de transação é necessário em seu sistema. Uma das supostas diferenças entre rel e não-rel dbs é o "consistente-sempre", "consistente-principalmente" ou "consistente-eventualmente". dbs de relação por padrão geralmente se enquadram na categoria "consistente-principalmente" e com algum trabalho, e muito bloqueio e condições de corrida,;) pode ser "consistente-sempre" para que todos estejam sempre olhando para a representação mais correta de um dado dado. A maior parte do que eu li/ouvi sobre dbs não-rel é que eles são principalmente "consistentes-eventualmente". Isso significa que pode haver muitas instâncias de nossos dados circulando, então o usuário "A" pode ver que temos 92 widgets no inventário, enquanto o usuário "B" pode ver 79, e eles podem não ser reconciliados até que alguém realmente vá para retirar coisas do armazém. Outra questão é a mutabilidade dos dados, com que frequência eles precisam ser atualizados? Os bancos de dados não rel específicos aos quais fui exposto têm mais sobrecarga para atualizações, alguns deles precisando regenerar todo o conjunto de dados para incorporar quaisquer atualizações.

Agora, lembre-se, acho que non-rel/nosql são ótimas ferramentas se realmente corresponderem ao seu caso de uso. Tenho vários que estou analisando agora para projetos que tenho. Mas você tem que olhar para todos os trade-offs ao tomar a decisão, caso contrário, apenas se transforma em um desenvolvimento mais direcionado ao currículo.