Articulo nuevo
MongoDB vs Cassandra: la comparativa util entre document database y wide-column distribuido
MongoDB y Cassandra resuelven problemas distintos. MongoDB prioriza modelado documental y flexibilidad de esquema. Cassandra, segun su documentacion oficial, se define como base de datos distribuida open source con modelo partitioned wide-column y semantica eventually consistent.
MongoDBCassandraWide-columnDocument databaseDistribuidoEventually consistent
Diferencias que evitan una mala eleccion
Basado en documentacion oficial de MongoDB y Apache Cassandra revisada el 23 de marzo de 2026.
MongoDB piensa en documentos; Cassandra piensa en particion y distribucion
Esa diferencia condiciona desde el modelado hasta la forma de consultar y operar.
Cassandra enfatiza semantica eventually consistent en su arquitectura
Es una pista clara de que su foco esta en disponibilidad y operaciones distribuidas a gran escala.
La eleccion depende mas del patron de acceso que del marketing de NoSQL
Si tu producto necesita documentos ricos y evolucion del modelo, MongoDB suele ser mas natural. Si vive de escritura distribuida y disponibilidad global extrema, Cassandra entra fuerte.
MongoDB y Cassandra no son equivalentes: una suele optimizar modelado documental y la otra arquitectura distribuida de alta disponibilidad
Si comparas ambas como si fueran dos sustitutos intercambiables, te vas a equivocar. Cassandra recompensa mas a quien diseña desde los patrones de particion y acceso en sistemas muy distribuidos. MongoDB recompensa mas a quien necesita una capa de persistencia flexible y cercana al dominio documental de la aplicacion.
MongoDB suele encajar mejor cuando
El dato es rico, anidado, cambiante y se consume como documento completo desde la aplicacion.
Cassandra suele encajar mejor cuando
El problema prioriza escritura distribuida, replicacion amplia, disponibilidad y una estrategia de particion muy clara.
Evento IoT agrupado por dispositivo dentro de un documento
db.deviceEvents.insertOne({
deviceId: "sensor-7",
timestamp: ISODate("2026-03-23T10:15:00Z"),
metrics: {
temperature: 21.4,
humidity: 42
},
location: { site: "madrid-1" }
})
db.deviceEvents.find({
deviceId: "sensor-7",
"location.site": "madrid-1"
})El foco está en guardar un evento rico y consultarlo como documento completo o filtrado por campos internos.
Tabla pensada desde la partition key y el patrón de acceso
CREATE TABLE device_events (
device_id text,
event_day date,
event_ts timestamp,
temperature double,
humidity int,
site text,
PRIMARY KEY ((device_id, event_day), event_ts)
) WITH CLUSTERING ORDER BY (event_ts DESC);
SELECT event_ts, temperature, humidity
FROM device_events
WHERE device_id = 'sensor-7'
AND event_day = '2026-03-23';La consulta está guiada por la clave de partición; primero diseñas el acceso, después la tabla.
Diferencia de ecosistema
MongoDB suele orbitar alrededor de documentos, colecciones y servicios gestionados como Atlas. Cassandra se mueve más cerca de topologías distribuidas, replicación, nodos y diseño por partition key.
Diferencia operativa
MongoDB pide pensar en agregados y evolución del modelo. Cassandra exige pensar antes en distribución, patrón de acceso y coste de consultas fuera de clave.
Tabla de decision en palabras
Elige MongoDB si tu problema principal es dato de producto, contenido, catalogos, esquemas flexibles o agregados de aplicacion. Elige Cassandra si el primer requisito es escritura distribuida siempre disponible, acceso predecible por partition key y replicacion entre nodos o regiones.
Error habitual
El error habitual es empezar por la marca de base de datos y no por el patron de acceso. Cassandra castiga las consultas improvisadas. MongoDB castiga el crecimiento documental sin control y las relaciones modeladas sin limite claro de agregado.