Estimador de tamanho de carga do IndexedDB

• Estimativa precisa do armazenamento do IndexedDB: nosso estimador calcula o tamanho de serialização da clonagem estruturada — o algoritmo real que o IndexedDB usa para armazenar objetos —, incluindo a sobrecarga por tipo de campo de strings, números, booleanos, arrays e objetos aninhados.
• Compressão LZ-String instantânea para o IndexedDB: comprima cargas JSON com LZ-String direto no navegador e veja a economia exata de armazenamento antes de escrever uma única linha de código. Nosso estimador mostra os tamanhos de saída UTF-16 e Base64 lado a lado.
• Estimador de tamanho de carga do IndexedDB online e seguro: suas cargas JSON nunca saem do seu dispositivo. Toda a estimativa da clonagem estruturada e a compressão LZ-String acontecem localmente no navegador — sem envio a servidor, sem processamento na nuvem, privacidade total para dados sensíveis de aplicações.
• Estimador de tamanho de carga do IndexedDB sem instalação: estime o armazenamento do IndexedDB e comprima cargas direto no navegador sem baixar software, sem plugins e sem conta. Funciona em qualquer navegador moderno e qualquer sistema operacional.

• Otimização do armazenamento offline em PWAs: aplicações web progressivas que guardam respostas de API no IndexedDB se beneficiam da compressão LZ-String. Use o estimador para verificar se seu conjunto de dados offline cabe na cota do dispositivo antes de publicar — algo especialmente importante em celulares com pouco armazenamento.
• Planejamento de armazenamento de extensões de navegador: extensões do Chrome e Firefox usam IndexedDB para armazenamento persistente. Use o estimador para medir quanta cota o modelo de dados da sua extensão consome e se a compressão LZ-String o mantém dentro dos limites por extensão do navegador.
• Dimensionamento de esquemas de banco de dados no cliente: antes de implementar um banco no cliente com Dexie.js, PouchDB ou IndexedDB puro, use o estimador para modelar os esquemas dos seus object stores e estimar os requisitos totais de armazenamento de um conjunto de dados típico.
• Adaptador IndexedDB para Redux Persist e Zustand: bibliotecas de gerenciamento de estado que persistem no IndexedDB (redux-persist com idb-keyval, Zustand com middleware persist) podem atingir limites de cota com árvores de estado grandes. Use o estimador para medir seu estado serializado e decidir se a compressão LZ-String é necessária.
• Prevenção de QuotaExceededError: um QuotaExceededError em produção é uma falha grave para os usuários. Use o estimador para medir proativamente suas maiores cargas e adicionar compressão LZ-String antes de atingir o teto de cota — especialmente no iOS Safari, que tem limites mais rígidos.
• Modelagem de dados para aplicações offline-first: aplicações offline-first que sincronizam grandes conjuntos de dados (documentos, metadados de imagens, histórico do usuário) precisam planejar bem o armazenamento. Use o estimador para comparar o armazenamento bruto e comprimido de cada object store e montar um orçamento de cota realista.

O IndexedDB é o banco de dados NoSQL embutido no navegador — ele armazena objetos JavaScript usando o algoritmo de clonagem estruturada, que serializa cada tipo de valor com uma sobrecarga específica: strings em UTF-16 (2 bytes por caractere), números com 8 bytes, booleanos com 1 byte e objetos/arrays com cerca de 50 bytes de sobrecarga de contêiner cada. Nosso estimador calcula esse tamanho de clonagem estruturada para qualquer carga JSON e depois mostra quanto a compressão LZ-String reduz a pegada de armazenamento — para que você decida com informação se vale comprimir seus valores do IndexedDB antes de armazená-los.

1. 1 Cole sua carga JSON: insira qualquer objeto, array ou string JSON que você pretende armazenar no IndexedDB. O estimador analisa o JSON e calcula o tamanho da clonagem estruturada — seus dados nunca saem do navegador.
2. 2 Escolha um formato de armazenamento: selecione JSON bruto (referência), LZ-String UTF-16 (mais eficiente em espaço para valores de string) ou LZ-String Base64 (portátil e seguro para URL). O estimador comprime a carga e mostra a economia exata de armazenamento.
3. 3 Revise as métricas e copie o trecho: o painel de métricas mostra o tamanho da clonagem estruturada, o tamanho do JSON bruto, o tamanho UTF-8 e o tamanho comprimido com barras visuais — além de um trecho de código IndexedDB pronto para usar com o formato de compressão escolhido.

• Tamanho da clonagem estruturada: os bytes estimados que o IndexedDB usa para armazenar o objeto nativamente — inclui sobrecarga por tipo de campo para strings (UTF-16), números (8 bytes), booleanos (1 byte) e sobrecarga de contêiner para objetos e arrays.
• String JSON bruta: o tamanho em bytes de JSON.stringify(data) armazenado como string UTF-16 no IndexedDB — muitas vezes menor que a clonagem estruturada em objetos profundamente aninhados.
• Bytes UTF-8: o tamanho em bytes se o JSON fosse armazenado em UTF-8 (por exemplo, em um Blob ou ArrayBuffer) — útil para comparar com o armazenamento do servidor.
• Comprimido com LZ-String: o tamanho em bytes após a compressão LZ-String — normalmente 50 a 80% menor que o JSON bruto em estruturas repetitivas como arrays de objetos semelhantes.

A estimativa do tamanho da clonagem estruturada é uma aproximação — a sobrecarga real do motor do navegador varia conforme o navegador e a versão. O V8 do Chrome e o SpiderMonkey do Firefox usam representações internas diferentes. Para medições precisas, use navigator.storage.estimate() antes e depois de escrever no IndexedDB na sua aplicação real. A cota do IndexedDB é dinâmica — normalmente 50% do espaço em disco disponível — e varia bastante entre navegadores de desktop, navegadores móveis e iOS Safari (que tem limites mais rígidos de cerca de 50 MB por origem).