Definición
NoSQL agrupa a las bases de datos que no siguen el modelo relacional de tablas y SQL. El nombre es malo —se lee como "sin SQL" cuando la intención era not only SQL— y agrupa cosas muy distintas entre sí.
Nacieron a finales de los 2000 en empresas con un problema muy concreto: volúmenes de datos que ya no cabían en un solo servidor. La respuesta fue renunciar a parte de las garantías de una base relacional a cambio de poder repartir los datos entre muchas máquinas.
Esa frase contiene lo esencial: NoSQL es un intercambio, no una mejora. Ganas escala o flexibilidad y pagas con consistencia, con consultas más limitadas o con trabajo que se traslada a tu código.
Los cuatro tipos
Documentos (MongoDB, CouchDB). Guardan objetos tipo JSON. Cada documento puede tener campos distintos. Bien cuando la estructura varía mucho entre registros.
Clave-valor (Redis, Memcached). Un identificador y un valor, nada más. Rapidísimas. Es lo que se usa para caché y sesiones.
Columnares (Cassandra, HBase). Optimizadas para escribir cantidades enormes repartidas entre muchos servidores. Registros de eventos, telemetría.
Grafos (Neo4j). Guardan nodos y las relaciones entre ellos. Brillan cuando lo que importa son las conexiones: redes sociales, detección de fraude, recomendaciones.
Y hay una quinta que ha crecido con la IA: las bases vectoriales, pensadas para buscar por similitud entre embeddings.
Ejemplo práctico
En mis proyectos, la base de datos principal es siempre relacional. Y aun así hay NoSQL, en el sitio donde tiene sentido.
El caso claro es la búsqueda semántica. Los vectores de los términos del diccionario no son un problema relacional: no quieres "dame las filas donde X = Y", quieres "dame los diez más parecidos a este vector". Es otra operación, y una base relacional no está pensada para ella.
En esta web la solución fue aún más simple que montar una base vectorial: son 101 términos, así que los vectores caben en un fichero JSON de 382 KB que se descarga con la página y se compara en el navegador. NoSQL sin base de datos. Cuando el volumen es pequeño, a veces la respuesta correcta es un fichero.
El caso donde decidí que NO fue el CRM de IMDICA. Al plantear los expedientes de pedido —cada uno con su historial de eventos, de longitud variable— la tentación fue guardarlos como documentos. Pero esos expedientes tienen que cruzarse con clientes, con albaranes y con facturas para sacar informes. En cuanto necesitas cruzar, lo relacional gana. Se quedaron en tablas.
La regla práctica
La pregunta que decide no es "¿cuál está más de moda?", sino ¿mis datos tienen relaciones que voy a necesitar cruzar?
- Si la respuesta es sí —y en una empresa casi siempre lo es—, relacional.
- Si son documentos independientes que no se cruzan entre sí, o si necesitas escribir a una escala que no cabe en un servidor, mira NoSQL.
Y un matiz importante que se ignora mucho: las bases relacionales modernas ya guardan JSON. PostgreSQL y MySQL tienen tipos JSON con índices. Muchas veces, "necesito flexibilidad de documentos" se resuelve con una columna JSON dentro de una tabla, sin renunciar a nada.
Errores comunes
- Elegirlo por moda. Mucho proyecto en MongoDB acaba reimplementando a mano los
JOINque la base relacional le habría dado gratis. - Creer que "sin esquema" es una ventaja. El esquema no desaparece: se muda a tu código, donde nadie lo hace cumplir. A los dos años tienes documentos de cinco formas distintas.
- Asumir consistencia inmediata. Muchas NoSQL son "consistentes al final": escribes y una lectura inmediata puede devolver el valor viejo. Para un saldo o un stock, eso es un problema serio.
- Usarlo para datos que sí son relacionales. Facturas, pedidos y clientes son el ejemplo canónico de datos relacionales.
- No pensar en las copias de seguridad. Cada motor tiene su procedimiento, y no siempre es tan simple como el de una base relacional.
Cuándo usarlo
Sí para caché y sesiones (Redis, y aquí es la respuesta obvia), para búsqueda por similitud, para volúmenes muy grandes de eventos, para datos genuinamente sin estructura fija, y para problemas donde las relaciones son el dato en sí (grafos).
No como base de datos principal de una aplicación de gestión. Ahí lo relacional lleva cincuenta años ganando por buenos motivos.
Lo habitual en un sistema serio no es elegir uno u otro: es relacional para el núcleo, y una pieza NoSQL para lo que la relacional hace mal.
