BSON

BSON (Binary JSON) é o formato de dados binários que o MongoDB usa para armazenamento e comunicação via rede. Com estrutura de objeto/array JSON na camada da API — mas binário no disco e na rede.

Por que um formato binário quando o JSON existe:

• Fidelidade de tipo. O JSON tem apenas string, number, boolean, null, object, array. O BSON adiciona Date, Binary, ObjectId, Decimal128, Regex, Timestamp, Int32 vs Int64. Idas e vindas pelo BSON preservam o tipo exato.
• Cabeçalhos de comprimento autodescritivos. Cada documento e valor BSON é prefixado com seu comprimento, para que o MongoDB possa pular campos sem analisá-los. O JSON requer leitura desde o início.
• Aritmética decimal. O tipo Decimal128 do BSON armazena números decimais exatos com até 34 dígitos significativos — importante para dados financeiros onde os floats IEEE 754 arredondam mal.

Os arquivos BSON são tipicamente 10-20% maiores do que o JSON equivalente por causa dos cabeçalhos de comprimento e tags de tipo explícito, mas o desempenho das consultas é dramaticamente mais rápido porque o MongoDB não precisa analisar o documento para encontrar um campo.

A maioria dos drivers do MongoDB (Node, Python, Java, Go) converte automaticamente entre BSON e os tipos nativos da linguagem. Você raramente interage com o BSON diretamente, a menos que esteja escrevendo um driver ou lendo os arquivos de backup bson fora do próprio MongoDB.

O limite de 16 MB por documento: um único documento BSON não pode exceder 16 megabytes. Essa é uma limitação rígida do servidor MongoDB, não do especificação BSON — o formato em si usa comprimentos assinados de 32 bits e teoricamente poderia chegar a 2 GB. O limite de 16 MB protege contra casos de uso degenerados (armazenar livros inteiros ou binários de imagem dentro de um documento) e corresponde ao tamanho da janela típica de pacotes de rede. O crescimento do documento além do limite força uma solução alternativa com GridFS (dividir o payload em partes em vários documentos) ou um redesign onde grandes blobs ficam no armazenamento de objetos com o documento contendo uma referência.

Por que o ObjectId do BSON tem 12 bytes e não é um UUID: o _id padrão do MongoDB é um ObjectId de 12 bytes composto por um timestamp Unix de 4 bytes, um identificador de “processo” aleatório de 5 bytes (substitui a divisão mais antiga de machine-id/PID) e um contador incremental de 3 bytes. A estrutura fornece ordenação temporal (os documentos mais recentes são classificados naturalmente no final) e evita o custo de coordenação de um UUID4. O trade-off é 12 bytes vs 16 para UUID, que em um bilhão de documentos economiza 4 GB de armazenamento de chave primária. Coleções mais recentes frequentemente usam UUID v7 para compatibilidade entre bancos de dados. Relacionados: IEEE 754, BigInt. Referência: BSON Specification.

Exemplo prático

O documento JSON {"x": 1} tem 8 bytes como texto. O mesmo documento em BSON é 0C 00 00 00 10 78 00 01 00 00 00 00 — 12 bytes: 4 bytes de comprimento total, 1 byte de código de tipo (0x10 = int32), o nome do campo x como uma string terminada em nulo (2 bytes), 4 bytes para o valor inteiro e um terminador de documento de 1 byte. O JSON é menor para payloads minúsculos, mas o BSON vence em velocidade de análise e em documentos com tipos não string. Um exemplo do mundo real: armazenar uma transação financeira com um preço Decimal128 de 123,45 vai e volta exatamente pelo BSON; pelo JSON torna-se 123.45 como float e corre o risco de voltar como 123.44999999999999 em JavaScript. A representação Decimal128 tem 16 bytes independentemente da magnitude.

Quando e por que isso importa

Se você constrói qualquer aplicativo no MongoDB e persiste dinheiro, deve armazená-lo como Decimal128, não como um Number JavaScript serializado para JSON. Os esquemas do Mongoose padrão para Number, que se torna double em BSON, o que silenciosamente introduz arredondamento IEEE-754 em preços como 0,10 + 0,20. O mesmo se aplica a datas: armazenar datas como strings (“2026-01-15”) perde a ordenação indexável entre fusos horários; armazená-las como Date BSON preserva a precisão em milissegundos e permite que consultas de intervalo usem índices B-tree eficientemente. Ao migrar dados para dentro ou fora do MongoDB, use mongoexport --jsonFormat=canonical em vez do modo relaxed para preservar informações de tipo BSON pelo intermediário JSON. Referência: MongoDB Manual — BSON Types.