Existem muitas soluções NoSQL por aí, cada uma com seus pontos strongs e fracos, portanto, o que se segue deve ser tomado com um pouco de sal.
Mas, essencialmente, o que muitos bancos de dados NoSQL fazem é confiar na desnormalização e tentar otimizar o caso desnormalizado. Por exemplo, digamos que você esteja lendo uma postagem de blog junto com seus comentários em um banco de dados orientado a documentos. Muitas vezes, os comentários serão salvos junto com a postagem em si. Isso significa que será mais rápido recuperar todos eles juntos, pois eles são armazenados no mesmo local e você não precisa realizar uma associação.
Claro, você pode fazer o mesmo no SQL, e a desnormalização é uma prática comum quando se precisa de desempenho. É só que muitas soluções NoSQL são projetadas desde o início para serem sempre usadas dessa maneira. Você então obtém as compensações usuais: por exemplo, adicionar um comentário no exemplo acima será mais lento porque você precisa salvar o documento inteiro com ele. E depois de desnormalizar, você precisa cuidar para preservar a integridade dos dados em seu aplicativo.
Além disso, em muitas soluções NoSQL, é impossível fazer junções arbitrárias, portanto, consultas arbitrárias. Alguns bancos de dados, como o CouchDB, exigem que você pense antes das consultas necessárias e prepare-as dentro do banco de dados.
Em suma, tudo se resume a esperar um esquema desnormalizado e a otimizar as leituras para essa situação, e isso funciona bem para dados que não são altamente relacionais e que exigem muito mais leituras do que gravações.