Então, respondendo diretamente às perguntas...

O armazenamento sem esquema é certamente um motivo convincente para usar o MongoDB, mas, como você apontou, também é bastante fácil armazenar JSON em um RDBMS. O poder por trás do MongoDB está nas consultas avançadas em armazenamento sem esquema.

Se eu puder apontar uma pequena falha na ilustração sobre a atualização de um campo JSON, não é simplesmente uma questão de obter o valor atual, atualizar o documento e depois enviá-lo de volta ao banco de dados. Todo o processo deve ser envolvido em uma transação. As transações tendem a ser bastante diretas, até que você comece a desnormalizar seu banco de dados. Então, algo tão simples quanto gravar um upvote pode bloquear tabelas em todo o seu esquema.

Com o MongoDB, não há transações. Mas as operações quase sempre podem ser estruturadas de forma a permitir atualizações atômicas. Isso geralmente envolve algumas mudanças dramáticas nos paradigmas SQL, mas na minha opinião elas são bastante óbvias quando você para de tentar forçar objetos em tabelas. No mínimo, muitas outras pessoas enfrentaram os mesmos problemas que você enfrentará, e a comunidade Mongo tende a ser bastante aberta e aberta sobre os desafios que eles superaram.

Por "gravações seguras", suponho que você queira dizer a opção de ativar um "getLastError()" automático após cada gravação. Temos um wrapper muito fino sobre um DBCollection que nos permite um controle refinado sobre quando getLastError() é chamado. No entanto, nossa política não se baseia em quão "importantes" são os dados, mas sim se o código após a consulta espera que quaisquer modificações sejam imediatamente visíveis nas leituras a seguir.

De um modo geral, esse ainda é um indicador ruim e, em vez disso, migramos para findAndModify() para o mesmo comportamento. Na ocasião em que ainda chamamos explicitamente getLastError() é quando o banco de dados provavelmente rejeitará uma gravação, como quando inserimos() com um _id que pode ser uma duplicata.

Infelizmente, não posso falar se nossa política de backup/restauração é eficaz, pois ainda não tivemos que restaurar. Estamos seguindo as recomendações do MongoDB para backup; @mark-hillick fez um ótimo trabalho ao resumi-los. Estamos usando conjuntos de réplicas e migramos as versões do MongoDB, bem como introduzimos novos membros de réplica. Até agora não tivemos tempo de inatividade, então não tenho certeza se posso falar bem a este ponto.

Portanto, na minha experiência, o MongoDB oferece armazenamento de dados sem esquema com um conjunto de primitivas de consulta ricas o suficiente para que as transações possam ser substituídas por operações atômicas. Tem sido difícil desaprender mais de 10 anos de experiência em SQL, mas todos os problemas que encontrei foram resolvidos pela comunidade ou pela 10gen diretamente. Não perdemos dados ou tivemos qualquer tempo de inatividade que me lembro.

Para simplificar, o MongoDB é de longe o melhor ecossistema de armazenamento de dados que já usei em termos de consulta, manutenção, escalabilidade e confiabilidade. A menos que eu tivesse um aplicativo que fosse tão claramente relacional que eu não pudesse em sã consciência usar nada além de SQL, eu faria todos os esforços para usar o MongoDB.

Eu não trabalho para a 10gen, mas sou muito grato pelas pessoas que trabalham.