Última actualización: 2026-11-03

Contenido de esta página

• ¿Qué es una base de datos NoSQL?
• ¿Por qué nacieron las bases de datos NoSQL? El problema de escala de la web
• ¿Cómo funciona una base de datos NoSQL? Esquema flexible, escalado horizontal y consistencia eventual
• Tipos de bases de datos NoSQL: qué problema resuelve cada modelo
• Ejemplos de bases de datos NoSQL y las más usadas por modelo
• ¿Cuándo una base NoSQL es la respuesta equivocada?
• ¿Por dónde empezar? Una recomendación

Historia real. Desde 1998 existe un gestor de bases de datos, obra del programador Carlo Strozzi, con un nombre que hoy suena a otra cosa: NoSQL [1]. Lo curioso es que era relacional. Guardaba los datos en tablas de filas y columnas, dentro de archivos de texto comunes de UNIX, el sistema operativo de muchos servidores [1].

Lo que lo apartaba de la mayoría de gestores era el idioma. No usaba SQL, el lenguaje estándar para consultar bases de tablas. Se manejaba con comandos de consola encadenados, uno detrás de otro [1].

Años después, la etiqueta cambió de dueño. Un movimiento de bases de datos la adoptó para alejarse del modelo de tablas por completo. Strozzi dejó la aclaración en su propia página: a ese movimiento habría sido más apropiado llamarlo «NoREL», es decir, «no relacional» [1].

Su corrección explica el tema mejor que muchas definiciones. Lo que estas bases dejaron atrás no fue tanto el lenguaje SQL como la rigidez de la tabla [2]. La razón fue práctica, y la contaron los ingenieros de Google y Amazon que construyeron dos sistemas de esa época: repartir los datos entre muchas máquinas.

¿Qué es una base de datos NoSQL?

Una base de datos NoSQL es una base que no obliga a meter la información en tablas de filas y columnas con un formato fijo. Según el caso, guarda cada registro como un documento o lo asocia a una clave. También puede repartirlo en familias de columnas o conectarlo con otros en una red de puntos, llamada grafo [2].

Dos ideas sostienen esa definición. La primera es el esquema flexible: el esquema es la lista de campos que la base le exige a cada registro, y aquí puede variar de un registro a otro. La segunda es la escala horizontal, que significa crecer sumando máquinas en lugar de comprar una más grande. La guía de arquitectura de Microsoft lo resume en una frase, donde agregar datos quiere decir resumirlos en totales. Dice que las bases no relacionales, «también llamadas bases de datos NoSQL, se optimizan para esquemas flexibles, escala horizontal y patrones específicos de acceso o de agregación» [2].

La misma guía agrega el precio de esa flexibilidad. Estas bases suelen relajar algunos rasgos del modelo relacional, como la rigidez del esquema y el alcance de las transacciones, a cambio de escala o de agilidad [2]. Una transacción es un grupo de cambios que se aplican todos juntos o no se aplica ninguno.

¿Qué significa NoSQL?

NoSQL significa «no solo SQL» o «no SQL», según Amazon Web Services (AWS), el negocio de servicios en la nube de Amazon [3]. Las dos lecturas conviven, y la primera describe mejor lo que pasa hoy. Algunas de estas bases aceptan consultas parecidas a SQL; Microsoft, por ejemplo, presenta uno de sus servicios de documentos con consultas de ese estilo [2].

El nombre, entonces, engaña un poco. No habla de lo que estas bases son, sino de lo que no son. Por eso Strozzi proponía «NoREL»: el rasgo común no es el lenguaje, sino que no son relacionales [1].

¿Qué es una base de datos no relacional y es lo mismo que NoSQL?

Una base de datos no relacional es cualquier base que guarda los datos sin el modelo de tablas enlazadas por claves. En la práctica, es otro nombre para una base NoSQL. AWS advierte que los dos términos se usan a menudo como intercambiables [3], y Microsoft los presenta como sinónimos en su guía [2].

Las relacionales, en cambio, reparten la información en tablas que se conectan por columnas en común. Cómo funcionan esas tablas y sus claves está en la guía de bases de datos relacionales. Y si lo que busca es qué es una base de datos en general, empiece por la guía de bases de datos.

¿Por qué nacieron las bases de datos NoSQL? El problema de escala de la web

Las bases NoSQL nacieron cuando algunas empresas de internet tuvieron que guardar más datos y atender más usuarios de los que un solo servidor podía manejar [4] [5]. Dos artículos técnicos marcaron el camino: Bigtable, de Google, presentado en 2006, y Dynamo, de Amazon, presentado en 2007 [4] [5]. Los dos describen sistemas que reparten los datos entre muchas máquinas.

Bigtable llegó ocho años después del NoSQL de Strozzi. Fay Chang y otros ocho autores de Google lo describieron como un sistema de almacenamiento diseñado para escalar a petabytes de datos repartidos en miles de servidores comunes [4]. Un petabyte son mil terabytes. Para entonces, más de sesenta productos y proyectos de Google lo usaban, entre ellos Google Analytics, Google Finance y Google Earth [4]. El artículo es explícito en un punto: Bigtable no ofrece un modelo relacional completo [4].

Al año siguiente, Giuseppe DeCandia y otros ocho autores de Amazon presentaron Dynamo, un almacén de clave y valor [5]. El artículo arranca con la confiabilidad a escala masiva, que describe como uno de los grandes retos de Amazon.com [5]. Su diseño buscaba que siempre se pudiera escribir en él. Si dos copias de un dato no coincidían, aceptaba la escritura y dejaba el conflicto para resolverlo al momento de leer [5].

Las dos ideas terminaron juntas en otro proyecto. La documentación de Apache Cassandra cuenta que esta base nació en Facebook y combinó las técnicas de reparto y copia de Dynamo con el modelo de datos de Bigtable [6].

La línea de tiempo completa, desde los archivos de los años cincuenta, está en la historia de las bases de datos. Hadoop y su ecosistema para procesar datos repartidos son otra historia, la del big data.

¿Cómo funciona una base de datos NoSQL? Esquema flexible, escalado horizontal y consistencia eventual

Una base NoSQL funciona con tres decisiones de diseño que la separan de una relacional. Acepta registros con campos distintos, crece sumando máquinas y, en varios casos, permite que sus copias tarden un rato en ponerse de acuerdo. Cada decisión resuelve un problema y abre otro.

Esquema flexible: cada registro trae sus propios campos

En una base relacional, el esquema se revisa al escribir: si una fila no trae las columnas acordadas, la base la rechaza. Microsoft llama a eso esquema al escribir. En las bases de documentos, clave-valor y grafos, en cambio, el esquema se interpreta al leer [2].

MongoDB, un gestor de documentos, lo muestra bien. En su manual, cada registro es un documento hecho de pares de campo y valor, parecido a un objeto JSON, un formato de texto para intercambiar datos [7]. Dos documentos del mismo grupo, que MongoDB llama colección, pueden tener estructuras distintas [7].

Piense en el catálogo de una tienda en línea. Un café tiene origen, altura y tipo de tueste. Una prensa francesa tiene capacidad y material. En una tabla, cada producto arrastraría columnas vacías que no le corresponden; en un documento, cada uno trae solo lo suyo.

La flexibilidad no es gratis. Microsoft advierte que los documentos pueden crecer de tamaño y que las consultas a gran escala exigen diseñar con cuidado la forma de los datos [2]. El orden que la base ya no impone tiene que ponerlo el equipo.

Escalado horizontal: más máquinas en vez de una más grande

Escalar en horizontal es sumar servidores y repartir los datos entre ellos, en vez de cambiar el servidor por uno más potente; la diferencia entre las dos formas de crecer está explicada en la guía de big data. Las bases NoSQL suelen diseñarse para crecer en horizontal [2] [3]. El manual de MongoDB dice que este gestor escala de forma horizontal con una técnica llamada fragmentación: parte los datos según una clave y los distribuye entre un grupo de máquinas [7]. Bigtable, como se vio, se pensó para miles de servidores comunes [4].

Esto no significa que una relacional no pueda repartirse. Microsoft explica que, en una base relacional, escalar en horizontal en general requiere fragmentar o particionar los datos [2]. La diferencia está en el punto de partida: en las NoSQL, el reparto viene incluido en el diseño.

Consistencia eventual: las copias se ponen de acuerdo, pero no al instante

La consistencia eventual es la promesa de que todas las copias de un dato quedarán iguales con el tiempo, aunque no al mismo instante. El artículo de Dynamo la define así: el sistema está diseñado para que todas las actualizaciones lleguen a todas las copias, tarde o temprano [5]. La documentación de Cassandra describe su propio comportamiento con ese mismo término [6].

Una comparación inventada para ilustrar: una cooperativa tiene tres sedes y una cartelera en cada una. Cuando la gerencia publica un aviso, este llega a las tres, pero no en el mismo minuto. Durante ese rato, dos socios en sedes distintas pueden leer versiones diferentes.

A cambio de esa espera, el sistema puede seguir aceptando cambios aunque una parte falle; esa era la prioridad de Dynamo [5]. En algunas bases NoSQL, además, el nivel de exigencia se puede ajustar: Microsoft anota que, en las bases de documentos, la consistencia típica es ajustable por elemento [2].

El compromiso formal entre consistencia y disponibilidad cuando la red falla tiene nombre propio, el teorema CAP, y pertenece al terreno de la ingeniería de datos.

Tipos de bases de datos NoSQL: qué problema resuelve cada modelo

Los cuatro tipos principales de bases de datos NoSQL son las documentales, las de clave-valor, las de columnas (también llamadas de familias de columnas o de columnas anchas) y las de grafos [2]. Microsoft agrega otros modelos no relacionales más especializados, como los de series de tiempo y los de búsqueda [2]. Cada uno nació para un patrón de acceso distinto, es decir, para una forma típica de leer y escribir los datos. La tabla resume, en grandes líneas, qué problema resuelve cada modelo.

Modelo	Cómo guarda los datos	Problema que resuelve	Usos documentados
Documental	Documentos con campos con nombre, a menudo en formato JSON, que pueden incluir listas y subdocumentos [2]	Registros cuya forma cambia y que la aplicación lee completos; MongoDB señala que los documentos anidados reducen la necesidad de cruces costosos entre tablas [7]	Catálogos de productos, gestión de contenidos y perfiles de usuario [2] [3]
Clave-valor	Un valor guardado bajo una clave que no se repite; en casi todos estos almacenes, el valor solo se lee, se escribe o se borra a través de su clave [2]	Buscar un dato por su clave con muy poca demora y crecer de forma lineal [2]	En Amazon: listas de más vendidos, carritos, preferencias de clientes, sesiones, posición en ventas y catálogo [5]; en general, memoria intermedia (caché) y sesiones [2]
De columnas	Filas con muchos campos vacíos y columnas que se agrupan en familias, según cómo se consultan juntas [2]	Un volumen alto de escrituras y lectura eficiente de datos anchos o dispersos [2]	En Google: más de sesenta productos sobre Bigtable, como Google Analytics y Google Earth [4]; en general, telemetría de sensores (las mediciones que los aparatos envían sin parar) y personalización [2]
De grafos	Puntos, llamados nodos, unidos por líneas que son las relaciones; unos y otros pueden llevar atributos, y no hay tablas ni documentos [8]	Recorrer conexiones de profundidad variable sin cruzar tablas, porque las relaciones se guardan junto a los nodos [2] [8]	Redes sociales, anillos de fraude, grafos de conocimiento y cadenas de suministro [2]; motores de recomendación [3]

Un detalle de nombres evita confusiones. En el mundo NoSQL, «de columnas» quiere decir familias de columnas, como Bigtable o Cassandra [2] [6]. No es lo mismo que los almacenes analíticos, pensados para resumir grandes volúmenes de historia en informes [2]; esos tienen su lugar en la ingeniería de datos.

Cómo encajan estos cuatro modelos entre todos los tipos de bases de datos, incluidas las relacionales, está en la guía de tipos de bases de datos.

Ejemplos de bases de datos NoSQL y las más usadas por modelo

Cuatro ejemplos de bases de datos NoSQL, uno por modelo, son MongoDB para documentos, Redis para clave-valor, Apache Cassandra para columnas y Neo4j para grafos. Cada uno aparece aquí porque su propia documentación lo ubica en ese modelo. La tabla suma, por modelo, otros productos con documentación oficial.

Modelo	Ejemplos de bases NoSQL	Qué dice la documentación oficial
Documental	MongoDB; Amazon DocumentDB; Azure Cosmos DB for NoSQL	MongoDB guarda cada registro como un documento de pares de campo y valor (manual 9.0, la versión vigente al 3 de noviembre de 2026) [7]. Amazon describe DocumentDB como una base de documentos JSON nativa y administrada [3]. Microsoft presenta Cosmos DB for NoSQL como una base sin esquema fijo y repartida en varias regiones [2]
Clave-valor	Redis; Amazon DynamoDB; Azure Cosmos DB for Table	En Redis, cada elemento tiene una clave única y todos viven en un mismo espacio de claves; su nombre viene de Remote Dictionary Server, «servidor de diccionario remoto» [9]. Amazon diseñó DynamoDB para dar un rendimiento constante con demoras de milisegundos de un dígito [3]. Microsoft describe Cosmos DB for Table como un almacén de clave y valor [2]
De columnas	Apache Cassandra; Apache HBase; Amazon Keyspaces	Cassandra usa un modelo de columnas anchas repartido en particiones, es decir, en trozos de datos que pueden vivir en máquinas distintas [6]; su versión estable más reciente es la 5.0.9, publicada el 7 de agosto de 2026 [10]. HBase se presenta como un almacén de big data modelado a partir de Bigtable [11]. Amazon describe Keyspaces como una base de columnas anchas administrada [3]
De grafos	Neo4j; Amazon Neptune	Neo4j guarda los datos como nodos, relaciones y propiedades, y no usa los cruces entre tablas de las bases SQL [8]. Amazon presenta Neptune como un servicio administrado de bases de grafos [3]

¿Cuáles son las bases de datos no relacionales más usadas? Esta tabla no las ordena por popularidad, a propósito. Un listado de nombres no dice cuál le conviene a usted, y el modelo sí. Hay, eso sí, una señal práctica que no es un ranking: Amazon y Microsoft ofrecen servicios compatibles con MongoDB, Redis y Cassandra [3] [2]. Quien aprende uno de esos tres encuentra más de un proveedor que lo ofrece [2] [3].

Para comparar el software en sí, con su licencia y su costo, está la guía de gestores de bases de datos.

¿Cuándo una base NoSQL es la respuesta equivocada?

Una base NoSQL es mala elección cuando varios cambios deben ocurrir juntos o no ocurrir. También lo es cuando hay que cruzar datos de formas no previstas o cuando mandan reglas estrictas entre tablas. Para esas necesidades, la guía de Microsoft recomienda una base relacional [2]. Las fortalezas que le atribuye son las transacciones que abarcan varias filas, los cruces complejos y las restricciones fuertes entre tablas [2].

Estos son los cuatro criterios para reconocer el caso:

1. Transacciones que tocan varios registros. Si mover plata de una cuenta a otra exige que los dos cambios ocurran juntos, la regla de Microsoft es clara: transacciones estrictas entre varias entidades, base relacional [2]. Dynamo solo permitía actualizar una clave a la vez [5]. Bigtable admitía transacciones de una sola fila y no transacciones generales entre filas [4]. Cassandra, por diseño, no implementa transacciones entre particiones, que son los trozos en que reparte los datos [6].
2. Cruces de datos que nadie previó. Cassandra tampoco implementa cruces repartidos entre tablas [6]. Microsoft lo plantea como señal para revisar la elección: si en una base de documentos crecen las consultas improvisadas que cruzan datos, conviene agregar un modelo relacional para leerlos [2].
3. Reglas de integridad entre tablas. Una clave foránea es la regla que impide, por ejemplo, registrar una venta de un cliente que no existe. Cassandra no implementa claves foráneas ni integridad referencial [6]. En una relacional, esa regla la hace cumplir la base.
4. Un problema que una sola base ya resuelve. Microsoft advierte contra repartir los datos entre varios servicios antes de tiempo: si uno solo todavía cumple los objetivos de rendimiento, escala y gobierno (las reglas sobre quién usa los datos y cómo), conviene quedarse con él [2]. Entre los errores comunes cuenta agregar otro modelo sin la madurez para operarlo, como monitoreo o copias de seguridad [2].

No hay que caricaturizar. MongoDB admite transacciones que abarcan varios documentos [12]. Su manual, sin embargo, advierte que en la mayoría de los casos esas transacciones cuestan más que escribir un solo documento y no reemplazan un buen diseño del esquema [12]. Que una base NoSQL pueda hacer algo no la vuelve la mejor herramienta para hacerlo.

Otro caso inventado, para aterrizar los criterios: la red de bibliotecas públicas de un municipio de Santander. Sus fichas mezclan libros, revistas y mapas, cada uno con campos distintos, y eso encaja en una base de documentos, que Microsoft asocia a la gestión de contenidos [2]. Saber qué ejemplar está prestado y a quién es llevar un inventario, uno de los usos que Microsoft le da a la relacional [2]. Y si un día quiere sugerir lecturas según lo que leyeron otros usuarios, eso es un motor de recomendación, que AWS cuenta entre los usos de los grafos [3].

Usar varios modelos a la vez se llama persistencia políglota. Microsoft la justifica porque un solo almacén rara vez sirve bien para todos los usos [2].

¿Por dónde empezar? Una recomendación

Lo que sigue es opinión mía. Para un equipo pequeño, como el de una pyme o una oficina pública de Colombia, el punto de partida sensato es una base relacional. NoSQL entra después, cuando un patrón de acceso concreto lo pide: sesiones que se consultan sin parar, un catálogo que cambia de forma cada temporada, una red de relaciones que hay que recorrer.

Lo digo por el costo que no aparece en la factura. Repartir datos entre varias máquinas y vigilar copias que tardan en ponerse de acuerdo exige gente que sepa operarlo. Microsoft pone en su lista de errores justo eso: sumar modelos sin la madurez para operarlos [2]. Una empresa grande absorbe ese costo. Una tienda de cinco personas en Bucaramanga lo paga con noches sin dormir.

Strozzi tenía razón con su «NoREL». La pregunta útil nunca fue si usar SQL o no. Fue si sus datos caben en una tabla, y si su negocio necesita, de verdad, más de una máquina.

Preguntas frecuentes

¿MongoDB es una base de datos NoSQL? Sí, del modelo documental. En MongoDB, cada registro es un documento de pares de campo y valor, parecido a un objeto JSON [7]. Eso no le impide ofrecer transacciones de varios documentos, aunque su propio manual recomienda no apoyarse en ellas como sustituto de un buen diseño [12].

¿Las bases de datos NoSQL usan SQL? Algunas sí, con matices. El nombre se lee como «no solo SQL» [3], y Microsoft presenta Cosmos DB for NoSQL con un lenguaje de consulta parecido a SQL [2]. Redis, en cambio, se maneja con comandos propios que guardan y leen valores por su clave [9]. Cada producto define su forma de consultar.

¿Qué significa que una base de datos NoSQL sea escalable? Quiere decir que puede atender más datos y más usuarios agregando servidores, sin cambiar el que ya tiene por uno más grande. MongoDB lo hace partiendo los datos según una clave y repartiéndolos entre varias máquinas [7]. Ese crecimiento tiene un costo operativo: más equipos que vigilar, actualizar y respaldar.

¿Las bases NoSQL son más rápidas que las relacionales? Depende de la pregunta que se les haga. Para buscar un valor por su clave, una base clave-valor ofrece muy poca demora [2]. Para cruzar datos de varias tablas con condiciones complejas, Microsoft recomienda la relacional [2]. La velocidad no es una propiedad del tipo de base, sino del encaje entre la base y la consulta.

¿Una base de datos NoSQL sirve para big data? Varias nacieron justo para eso. Bigtable se diseñó para petabytes repartidos en miles de servidores [4], y Apache HBase se presenta como un almacén de big data modelado a partir de Bigtable [11]. Aun así, guardar datos y analizarlos son tareas distintas; el análisis a gran escala tiene su propio terreno en el big data.

Referencias

Las citas en otro idioma son traducción propia.

1. Carlo Strozzi. NoSQL: a non-SQL RDBMS, página del proyecto (Copyright 1998-2017) — NoSQL es un gestor de bases de datos relacionales, existe desde 1998, no es una base SQL sino una herramienta de consola que no usa SQL como lenguaje de consulta, sus operadores se encadenan con tuberías de UNIX y sus datos viven en archivos ASCII comunes de UNIX con forma de tabla; no tiene relación con el movimiento NoSQL, que se aparta por completo del modelo relacional y que, según el autor, debió llamarse más apropiadamente «NoREL». Carlo Strozzi: NoSQL, a non-SQL RDBMS — Consultada: 2026-11-03.
2. Microsoft. Understand data models, Azure Architecture Center (ms.date: 21 de agosto de 2025) — «Nonrelational databases, also called NoSQL databases, optimize for flexible schemas, horizontal scale, and specific access or aggregation patterns»; relajan la rigidez del esquema y el alcance de las transacciones a cambio de escala o agilidad; relacional: esquema al escribir, fortalezas en transacciones de varias filas, cruces complejos y restricciones fuertes, y escalar en horizontal en general requiere fragmentar o particionar; definiciones, fortalezas, consideraciones y cargas típicas de los modelos documental, de familias de columnas, clave-valor y grafo; esquema al leer y consistencia típica ajustable por elemento en documentos; Azure Cosmos DB for NoSQL con consultas parecidas a SQL, Azure DocumentDB compatible con el protocolo de MongoDB, Azure Managed Redis, Cosmos DB for Table y Managed Instance for Apache Cassandra; heurística «Strict multi-entity transactions → Relational»; señal de reevaluación por consultas improvisadas con cruces en una base de documentos; «Avoid premature fragmentation» (no repartir entre varios servicios mientras uno cumpla los objetivos de rendimiento, escala y gobierno) y el error de agregar otro modelo sin madurez operativa; «A single data store rarely satisfies all access patterns efficiently». Microsoft Learn: Understand data models — Consultada: 2026-11-03.
3. Amazon Web Services. What is NoSQL? — «NoSQL stands for not only SQL or non-SQL»; «Often the term NoSQL is used interchangeably with the term non-relational»; esquemas flexibles; diseño para escalar con clústeres de hardware repartidos; usos de documentos (catálogos, perfiles de usuario, gestión de contenidos) y de grafos (redes sociales, motores de recomendación, detección de fraude); productos: Amazon DynamoDB (rendimiento constante con latencia de milisegundos de un dígito), Amazon DocumentDB (con compatibilidad con MongoDB), Amazon Keyspaces (para Apache Cassandra), Amazon Neptune y Amazon ElastiCache (compatible con Redis). AWS: What is NoSQL? — Consultada: 2026-11-03.
4. Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes y Robert E. Gruber (Google). Bigtable: A Distributed Storage System for Structured Data, 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI), 2006, pp. 205-218 — diseñado para escalar a «petabytes of data across thousands of commodity servers»; usado por más de sesenta productos y proyectos de Google, entre ellos Google Analytics, Google Finance, Orkut, Personalized Search, Writely y Google Earth; no admite un modelo de datos relacional completo; admite transacciones de una sola fila y no transacciones generales entre claves de fila. Texto leído en la versión HTML de las actas de USENIX. Google Research: Bigtable (OSDI 2006) — Consultada: 2026-11-03.
5. Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasubramanian, Peter Vosshall y Werner Vogels (Amazon.com). Dynamo: Amazon’s Highly Available Key-value Store, Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP’07), Stevenson (Washington), 14-17 de octubre de 2007 — almacén de clave y valor de alta disponibilidad; la confiabilidad a escala masiva como uno de los grandes retos de Amazon.com; almacén «always writeable» que resuelve los conflictos al leer; «eventually consistent»: todas las actualizaciones llegan a todas las réplicas con el tiempo; servicios con acceso solo por clave primaria (listas de más vendidos, carritos, preferencias de clientes, gestión de sesiones, rango de ventas y catálogo); sin garantías de aislamiento y solo actualizaciones de una clave. Texto leído en la copia publicada por Werner Vogels, coautor (allthingsdistributed.com, 2 de octubre de 2007). ACM: Dynamo, SOSP 2007 (DOI) — Consultada: 2026-11-03.
6. The Apache Software Foundation. Apache Cassandra Documentation 5.0: Overview (arquitectura) — base de datos NoSQL de código abierto y repartida, con un modelo de columnas anchas particionado y semántica de consistencia eventual; diseñada inicialmente en Facebook, combinó las técnicas de almacenamiento repartido y replicación de Dynamo con el modelo de datos y de almacenamiento de Bigtable; elige no implementar operaciones que exijan coordinación entre particiones: transacciones entre particiones, cruces repartidos y claves foráneas o integridad referencial. Apache Cassandra: Overview — Consultada: 2026-11-03.
7. MongoDB, Inc. What is MongoDB?, Database Manual 9.0 (versión vigente) — un registro es un documento, estructura de pares de campo y valor, parecida a los objetos JSON; los documentos y arreglos anidados reducen la necesidad de cruces costosos; los esquemas dinámicos permiten estructuras distintas en una misma colección; escala horizontal nativa mediante fragmentación (sharding), que parte los datos según una clave y los distribuye entre un grupo de máquinas. MongoDB: Database Manual, What is MongoDB? — Consultada: 2026-11-03.
8. Neo4j. What is a graph database, Getting Started — una base de grafos de Neo4j guarda los datos como nodos, relaciones y propiedades en lugar de tablas o documentos; las bases de grafos no usan JOIN; las relaciones se guardan de forma nativa junto a los nodos. Neo4j: What is a graph database — Consultada: 2026-11-03.
9. Redis. Redis as an in-memory data structure store quick start guide — Redis significa Remote Dictionary Server; los datos se guardan y se recuperan con una clave (comandos SET y GET); cada elemento tiene una clave única y todos viven en el espacio de claves de Redis. Redis Docs: data structure store quick start — Consultada: 2026-11-03.
10. The Apache Software Foundation. Apache Cassandra: Downloads — última versión estable (GA): Apache Cassandra 5.0.9, publicada el 2026-08-07. Apache Cassandra: Downloads — Consultada: 2026-11-03.
11. The Apache Software Foundation. Apache HBase (página del proyecto) — «The Hadoop Database»: almacén de big data repartido y escalable para lectura y escritura aleatorias en tiempo real; «modeled after Google Bigtable». Apache HBase: página del proyecto — Consultada: 2026-11-03.
12. MongoDB, Inc. Transactions, Database Manual 9.0 — MongoDB admite transacciones de varios documentos; en la mayoría de los casos una transacción distribuida tiene un costo de rendimiento mayor que la escritura de un solo documento y no debe reemplazar un diseño de esquema eficaz; en muchos escenarios el modelo desnormalizado (documentos y arreglos anidados) sigue siendo el óptimo. MongoDB: Database Manual, Transactions — Consultada: 2026-11-03.

Cómo investigamos esta página

• Pregunta que responde: Qué son las bases de datos NoSQL o no relacionales, de qué problema nacieron, qué resuelve cada modelo y cuándo no conviene usarlas.
• Fuentes: identificadas 63 → incluidas 12
• Criterios de inclusión: artículos originales de Bigtable y Dynamo, documentación oficial de Microsoft, AWS, MongoDB, Cassandra, HBase, Redis y Neo4j, y la página del autor del primer NoSQL; nada de enciclopedias, blogs ni rankings.
• Fecha de corte de los datos: 2026-11-03