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 databaseDistribuidoConsistencia ajustable
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 ajusta la consistencia en cada consulta; MongoDB centraliza las escrituras en un primario
Cassandra cambia consistencia por disponibilidad consulta a consulta (ONE, QUORUM, ALL). En MongoDB los replica sets escriben en un primario y añaden read/write concern y transacciones multidocumento.
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.
Comparativa lado a lado
| Aspecto | MongoDB | Cassandra |
|---|---|---|
| Modelo de datos | Documentos BSON tipo JSON en colecciones; campos anidados y arrays. | Tablas con filas agrupadas por clave de partición y ordenadas por columnas de clustering. |
| Escrituras y replicación | Replica set: se escribe en el primario y se replica a los secundarios; el sharding reparte por shard key. | Anillo sin maestro: cualquier nodo acepta escrituras; los datos se replican en N nodos por centro de datos. |
| Consistencia | Lecturas fuertes desde el primario por defecto; ajustable con read y write concern. | Ajustable en cada consulta (ONE, QUORUM, LOCAL_QUORUM, ALL); leer y escribir con QUORUM garantiza leer lo escrito. |
| Transacciones | Transacciones ACID multidocumento (replica sets desde 4.0, clústeres sharded desde 4.2). | Lightweight transactions en una sola partición (compare-and-set); sin transacciones generales multifila. |
| Consultas | Consultas ricas, índices secundarios y aggregation pipeline. | CQL pensado para la clave de partición; los Storage-Attached Indexes (SAI) de Cassandra 5 amplían opciones, pero las tablas se siguen modelando por consulta. |
| Límites a recordar | 16 MB como máximo por documento; los arrays sin límite son mala señal de diseño. | Las particiones muy grandes degradan el rendimiento; mantenlas acotadas (por ejemplo, por día). |
| Licencia | Server Side Public License (SSPL) en el servidor Community; Atlas como servicio gestionado. | Apache License 2.0; opciones gestionadas de varios proveedores cloud. |
En MongoDB los índices siguen importando: el ejemplo anterior necesita un índice en deviceId (y en location.site si filtras por él) para evitar recorrer toda la colección.
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.