O armazenamento de tabelas é um recurso de armazenamento central do Windows Azure, projetado para ser escalável (100 TB 200 TB 500 TB por conta), durável (replicado triplamente no data center, opcionalmente georeplicado para outro data center) e sem esquema (cada linha pode conter as propriedades desejadas). Uma linha é localizada por chave de partição + chave de linha, fornecendo uma pesquisa muito rápida. Todo o acesso ao Table Storage é feito por meio de uma API REST bem definida, utilizável em qualquer linguagem (com SDKs, construídos sobre as APIs REST, já existentes para .NET, PHP, Java, Python e Ruby).

MongoDB é um banco de dados orientado a documentos. Para executá-lo no Azure, você precisa instalar o MongoDB em uma web/funções de trabalho ou máquina virtual, apontá-lo para uma unidade de nuvem (fornecendo assim uma letra de unidade) ou disco anexado (para máquinas virtuais Windows/Linux), opcionalmente ativar o registro no diário (o que eu recomendo) e, opcionalmente, defina um endpoint externo para seu uso (ou acesse-o via rede virtual). O Cloud Drive/disco anexado, aliás, é na verdade armazenado em um Azure Blob, dando a você a mesma durabilidade e georreplicação que o Azure Tables.

Ao comparar os dois, lembre-se de que o Table Storage é Storage-as-a-Service:basta acessar um endpoint REST conhecido. Com o MongoDB, você é responsável por manter o banco de dados (por exemplo, sempre que o MongoDB Inc (anteriormente 10gen) lançar uma nova versão do MongoDB, você precisará atualizar seu servidor de acordo).

Em relação à versão alfa do MongoDB Inc apontada por jtoberon:Se você olhar de perto, verá algumas coisas importantes:

• A configuração é para uma instância autônoma do mongodb, sem conjuntos de réplicas ou fragmentos. Em relação aos conjuntos de réplicas, você ainda obtém vários benefícios usando a versão Standalone, devido à forma como o armazenamento de blobs funciona.
• Para fornecer alta disponibilidade, você pode executar com várias instâncias. Nesse caso, apenas uma instância atende ao banco de dados e uma é um 'warm-standby' que inicia o processo mongod assim que a outra instância falha (para reinicialização de manutenção, falha de hardware etc.).

Embora o wrapper do Windows Azure da 10gen ainda seja considerado 'alfa', o mongod.exe não é. Você pode iniciar o exe mongod como faria com qualquer outro exe do Windows. É apenas o código de gerenciamento em torno do lançamento, e é isso que a implementação do alpa está demonstrando.

EDIT 2011-12-8:Isso não está mais em um estado alfa. Você pode baixar o projeto MongoDB+Windows Azure mais recente aqui, que fornece suporte para conjunto de réplicas.

Para desempenho, acho que você precisará fazer algum benchmarking. Dito isso, considere o seguinte:

• Ao acessar o armazenamento de tabelas ou o MongoDB de, digamos, uma função da Web, você ainda está entrando em contato com o sistema de armazenamento do Windows Azure.
• MongoDB usa muita memória para seu próprio cache. Por esse motivo, muitos sistemas MongoDB de alta escala são implantados em instâncias maiores. Para acesso ao armazenamento de tabelas, você não terá a mesma consideração de tamanho de memória.

EDITAR 7 de abril de 2015 Se você quiser usar um banco de dados baseado em documento como serviço, o Azure agora oferece o DocumentDB.