BSON

BSON (Binary JSON) es el formato de datos binario que MongoDB usa para almacenamiento y comunicación a través de la red. Con forma de JSON a nivel de API (misma jerarquía de objetos y matrices), pero binario en disco y en la red.

Por qué un formato binario cuando existe JSON:

• Fidelidad de tipos. JSON solo tiene string, number, boolean, null, object, array. BSON añade Date, Binary, ObjectId, Decimal128, Regex, Timestamp, Int32 vs Int64. Los viajes de ida y vuelta a través de BSON preservan el tipo exacto.
• Cabeceras de longitud autodescriptivas. Cada documento y valor BSON tiene como prefijo su longitud, por lo que MongoDB puede saltar campos sin analizarlos. JSON requiere leer desde el principio.
• Aritmética decimal. El tipo Decimal128 de BSON almacena números decimales exactos de hasta 34 dígitos significativos, importante para datos financieros donde los flotantes IEEE 754 redondean mal.

Los archivos BSON suelen ser entre un 10-20% más grandes que el JSON equivalente, debido a las cabeceras de longitud y las etiquetas de tipo explícitas, pero el rendimiento de consulta es considerablemente más rápido porque MongoDB no tiene que analizar el documento para encontrar un campo.

La mayoría de los drivers de MongoDB (Node, Python, Java, Go) convierten automáticamente entre BSON y los tipos nativos del lenguaje. Rara vez interactúas con BSON directamente a menos que estés escribiendo un driver o leyendo los archivos de copia de seguridad bson fuera del propio MongoDB.

El límite de 16 MB por documento: un único documento BSON no puede superar los 16 megabytes. Esta es una restricción del servidor MongoDB, no un límite de la especificación BSON: el formato en sí usa longitudes de 32 bits con signo y podría alcanzar teóricamente los 2 GB. El límite de 16 MB protege contra casos de uso degenerados (almacenar libros enteros o binarios de imagen dentro de un documento) y coincide con el tamaño de la ventana de paquetes de red típica. El crecimiento de documentos más allá del límite obliga a una solución GridFS (dividir la carga en fragmentos a través de múltiples documentos), o a un rediseño donde los blobs grandes residan en almacenamiento de objetos con el documento conteniendo una referencia.

Por qué el ObjectId de BSON tiene 12 bytes y no es un UUID: el _id por defecto de MongoDB es un ObjectId de 12 bytes compuesto de un timestamp Unix de 4 bytes, un identificador aleatorio de “proceso” de 5 bytes (reemplaza la antigua división machine-id/PID) y un contador incremental de 3 bytes. La estructura proporciona ordenación temporal (los documentos más recientes se ordenan naturalmente al final) y evita el coste de coordinación de un UUID4. La compensación es 12 bytes frente a 16 para UUID, lo que en mil millones de documentos ahorra 4 GB de almacenamiento en clave primaria. Las colecciones más recientes suelen usar UUID v7 para mayor compatibilidad entre bases de datos. Relacionado: IEEE 754, BigInt. Referencia: BSON Specification.

Ejemplo práctico

El documento JSON {"x": 1} ocupa 8 bytes como texto. El mismo documento en BSON es 0C 00 00 00 10 78 00 01 00 00 00 00: 12 bytes: 4 bytes de longitud total, 1 byte de código de tipo (0x10 = int32), el nombre de campo x como cadena terminada en null (2 bytes), 4 bytes para el valor entero y 1 byte terminador del documento. JSON es más corto para cargas pequeñas, pero BSON gana en velocidad de análisis y en documentos con tipos no cadena. Un ejemplo del mundo real: almacenar una transacción financiera con un precio Decimal128 de 123,45 va y vuelve exactamente a través de BSON; a través de JSON se convierte en 123.45 como flotante y puede volver como 123.44999999999999 en JavaScript. La representación Decimal128 ocupa 16 bytes independientemente de la magnitud.

Cuándo y por qué importa

Si construyes cualquier aplicación sobre MongoDB y persistes dinero, deberías almacenarlo como Decimal128, no como un Number de JavaScript serializado a JSON. Los esquemas de Mongoose usan por defecto Number, que se convierte en double en BSON, lo que silenciosamente introduce redondeo IEEE-754 en precios como 0,10 + 0,20. Lo mismo aplica a las fechas: almacenar fechas como cadenas (“2026-01-15”) pierde el ordenamiento indexable entre zonas horarias; almacenarlas como Date BSON preserva la precisión en milisegundos y permite que las consultas de rango usen índices B-tree de forma eficiente. Al migrar datos hacia o desde MongoDB, usa mongoexport --jsonFormat=canonical en lugar del modo relaxed para preservar la información de tipo BSON a través del JSON intermedio. Referencia: MongoDB Manual — BSON Types.