Como o localStorage é diferente do indexedDB?

Na superfície, as duas tecnologias podem parecer diretamente comparáveis, no entanto, se você passar algum tempo com elas, logo perceberá que elas não são. Eles foram projetados para atingir um objetivo semelhante, o armazenamento no lado do cliente, mas eles abordam a tarefa em questão de perspectivas significativamente diferentes e funcionam melhor com diferentes quantidades de dados.

localStorage, ou mais precisamente Armazenamento na Web , foi projetado para pequenas quantidades de dados. É essencialmente um armazenamento de valor-chave apenas de strings , com uma API simplista síncrona . Essa última parte é fundamental. Embora não haja nada na especificação que proíba um armazenamento DOM assíncrono, atualmente todas as implementações são síncronas (ou seja, solicitações de bloqueio). Mesmo que você não tenha se importado em usar um armazenamento ingênuo de valores-chave para grandes quantidades de dados, seus clientes se importarão em esperar que seu aplicativo seja carregado.

indexedDB , por outro lado, foi projetado para trabalhar com quantidades significativamente maiores de dados. Primeiro, em teoria, ele fornece uma API síncrona e assíncrona. Na prática, no entanto, todas as implementações atuais são assíncronas e as solicitações não bloquearão o carregamento da interface do usuário. Além disso, indexedDB, como o nome revela, fornece índices . Você pode executar consultas rudimentares em seu banco de dados e buscar registros pesquisando as chaves deles em intervalos de chaves específicos . O indexedDB também suporta transações e fornece tipos simples (por exemplo, Data).

Neste ponto, indexedDB pode parecer a solução superior para qualquer situação. No entanto, há uma penalidade em todos os seus recursos: em comparação com o DOM Storage, sua API é bastante complicada. indexedDB pressupõe uma familiaridade geral com conceitos de banco de dados, enquanto que com DOM Storage você pode ir direto ao ponto. Se você já trabalhou com cookies, não terá um problema ao trabalhar com DOM Storage. Além disso, em geral, você precisará escrever mais código no indexedDB para obter exatamente o mesmo resultado que no DOM Storage (e mais código = mais bugs). Além disso, emular o DOM Storage para navegadores que não suportam é relativamente simples. Com indexedDB, a tarefa não valeria a pena. Por fim, antes de mergulhar no indexedDB, primeiro você deve dar uma olhada na API de cota .

No final do dia, depende totalmente de você usar o DOM Storage ou indexedDB, ou ambos, em seu aplicativo. Um bom caso de uso para o Armazenamento DOM seria armazenar dados de sessão simples, por exemplo, o nome de um usuário, e salvar algumas solicitações para o banco de dados real. Por outro lado, os recursos adicionais do indexedDB podem ajudá-lo a armazenar todos os dados necessários para que seu aplicativo funcione offline.

A resposta do @yannis é excelente. Só quero adicionar algumas coisas.

1. Em algumas situações, como os Service Workers, você não pode usar o código de bloqueio, portanto, não é possível usar localStorage e deve usar algo como indexedDB.

2. A API do indexedDB é complexa e tediosa (eu diria "horrível", YMMV). Existem várias bibliotecas "wrapper" para simplificar a API, sugiro strongmente que você olhe para elas.

Para mim, descobri que posso armazenar blobs no IndexedDB enquanto no localStorage posso armazenar apenas strings. Isso significa que o IndexdDB é melhor para dados binários como imagens, áudio e vídeo. Sim, podemos armazenar imagens em base64 no localStorage, mas os blobs serão menores e mais rápidos porque não precisamos decodificá-los.

Citações de MDN :

The keys and the values are always strings.

Sobre o IndexedDB :

Any objects supported by the structured clone algorithm can be stored:  
All primitive types However not symbols
Boolean object   
String object    
Date     
RegExp  The lastIndex field is not preserved.
Blob     
File     
FileList     
ArrayBuffer  
ArrayBufferView This basically means all typed arrays like Int32Array etc.
ImageData    
Array    
Object  This just includes plain objects (e.g. from object literals)
Map  
Set