MongoDB no almacena JSON ni objetos de JavaScript de forma directa. Almacena , una representación binaria y tipada de documentos. BSON conserva una estructura parecida a un objeto con pares campo-valor, pero añade tipos que JSON no puede expresar por sí solo, como , , , , enteros de 32 y 64 bits, timestamps internos y expresiones regulares.
BSON
ObjectId
Date
Decimal128
Binary
Comprender BSON es importante porque el tipo almacenado afecta:
Este documento contiene strings, boolean, array, subdocumento, fecha, ObjectId y tipos numéricos diferentes. Aunque en una interfaz visual varios puedan parecer “números”, no son necesariamente equivalentes.
JSON es útil para intercambiar información, pero tiene un conjunto de tipos limitado. No distingue de manera nativa entre enteros y números de punto flotante, no tiene un tipo de fecha, no representa bytes binarios ni identificadores especializados.
Una base de datos necesita conservar más información sobre cada valor. BSON resuelve ese problema incorporando un identificador de tipo junto al valor serializado.
Texto
valor en la aplicación
↓
driver aplica mapping
↓
valor BSON tipado
↓
MongoDB lo almacena, compara e indexa
↓
driver lo convierte al leer
El driver participa en ambos sentidos. Por eso el comportamiento puede variar según lenguaje y configuración. MongoDB Server conoce BSON; no conoce las clases, interfaces o tipos de dominio de la aplicación.
Un documento BSON es una secuencia ordenada de campos. Cada campo tiene:
un nombre;
un identificador de tipo;
un valor codificado.
El orden de campos suele ser irrelevante cuando se consulta por rutas individuales, pero puede importar cuando se compara un documento embebido completo por igualdad. Por ejemplo, estas formas pueden no ser equivalentes para una igualdad exacta sobre todo el subdocumento:
Representa texto UTF-8. Su comparación y orden pueden depender de la collation configurada. Guardar un número, fecha o estado estructurado como string puede dificultar rangos, orden y validación.
true y false son booleanos. null es un valor explícito y no equivale automáticamente a que el campo no exista. En consultas, la diferencia entre null, missing y tipos incorrectos debe evaluarse con cuidado.
Puede contener valores o documentos. Los arrays permiten representar relaciones one-to-few o información repetida, pero su crecimiento afecta tamaño, índices multikey y contention. BSON no impide arrays ilimitados; el diseño debe hacerlo.
BSON Date representa un instante como milisegundos desde Unix epoch, conceptualmente en UTC. No conserva por sí mismo el nombre de la zona horaria original.
Si el dominio necesita recordar que una cita fue programada en America/Bogota, guarda también esa información:
Es un identificador BSON de 12 bytes utilizado frecuentemente para _id. Tiene un componente temporal, pero no debe usarse como sustituto de createdAt cuando la fecha forma parte del dominio.
Representa números decimales con precisión decimal. Es útil para dinero y otros valores donde errores binarios de punto flotante son inaceptables.
JavaScript
{total:Decimal128('19900.50')}
El driver de Node.js devuelve normalmente un objeto Decimal128, no un number común. La aplicación debe decidir cómo validarlo, calcularlo y serializarlo sin perder precisión.
BSON Binary almacena bytes y puede utilizar subtipos, incluyendo representaciones de UUID. La estrategia de UUID debe ser consistente entre drivers y sistemas para evitar que la misma secuencia lógica se interprete de formas incompatibles.
El BSON timestamp se utiliza principalmente en mecanismos internos como replication. No es el tipo habitual para fechas de negocio. Para fechas de aplicación se utiliza normalmente BSON Date.
BSON puede almacenar expresiones regulares. Su existencia no convierte regex en un motor de búsqueda general. Patrones no anclados pueden producir scans costosos y riesgos de abuso si provienen de entrada no confiable.
Son valores especiales que ordenan antes o después de otros tipos. Aparecen principalmente en contextos internos, rangos e inspección. No suelen representar conceptos de dominio.
ObjectId y Decimal128 son tipos proporcionados por el paquete BSON usado por el driver.
Date de JavaScript se convierte a BSON Date.
stock se envía desde JavaScript como number; el tipo BSON efectivo depende de la representación y del driver.
Al leer, price no se convierte automáticamente a un número decimal seguro para cálculos financieros.
El cliente debe reutilizarse y cerrarse durante el shutdown, no después de cada operación.
En una aplicación real también existirían validación de entrada, manejo de errores, timeouts y una estrategia explícita para convertir valores de dominio.
MongoDB limita la profundidad de documentos anidados. Aunque una estructura esté lejos del límite técnico, demasiados niveles hacen difíciles las queries, updates, validation e índices.
MongoDB admite más casos de puntos y signos de dólar que versiones antiguas, pero existen restricciones y comportamientos que dependen del contexto, driver y herramientas. Utilizar nombres que comienzan con $ o contienen . sigue siendo una mala convención para schemas de aplicación porque colisiona con sintaxis de operadores y dot notation.
El límite de 16 MiB no vuelve seguro un array de 10 MiB que sigue creciendo. El problema puede aparecer mucho antes por multikey indexes, updates frecuentes, working set y hotspots.
El resultado de punto flotante binario puede no ser exactamente 0.3. Dos estrategias frecuentes son:
guardar unidades menores como entero, por ejemplo centavos;
utilizar Decimal128 de forma consistente.
La elección debe mantenerse en input, persistencia, cálculos, aggregations y respuestas. Convertir Decimal128 a number sin analizar rango y precisión puede eliminar el beneficio.
El driver serializa propiedades compatibles. Prototypes, métodos, getters y clases no se convierten en un objeto de dominio persistido con el mismo comportamiento.
Esto ayuda a detectar schema drift. En una colección grande debe aplicarse con filtros, muestras o procesos controlados para no ejecutar trabajo innecesario.
BSON es el contrato de persistencia real entre driver y servidor. Los tipos no son decoración: determinan precisión, comparación, indexación, serialización y evolución del schema. Diseñar documentos exige definir tipos intencionalmente y controlar null, missing, arrays, fechas y crecimiento.
Comprueba lo aprendido
¿Por qué JSON estándar no basta para representar fielmente todos los documentos MongoDB?
¿Qué se perdería al convertir Decimal128 a un number sin analizar precisión?
¿Cómo guardarías una cita futura cuando también importa la zona horaria elegida por el usuario?
¿Por qué un array puede ser problemático aunque el documento aún esté lejos de 16 MiB?
¿Qué diferencia práctica existe entre null, un campo missing y un string con apariencia numérica?