SQL vs NoSQL: cómo elegir bien en 2026

“Depende” es la respuesta correcta a SQL contra NoSQL, y también la más inútil si no viene acompañada de los criterios que determinan de qué depende. Este artículo es esa segunda parte: los criterios concretos, en el orden en que deberías aplicarlos, antes de que la discusión se convierta en una preferencia estética por el lenguaje de consulta.

Primero, una aclaración que evita media discusión mal planteada: SQL es un lenguaje de consulta, no un modelo de datos, y NoSQL (“not only SQL”) no es un modelo único sino una familia de al menos cuatro modelos distintos —documentos, clave-valor, columnar ancho y grafos— con características de consistencia y patrones de consulta muy diferentes entre sí. Comparar “SQL” contra “NoSQL” como si fueran dos cosas homogéneas es la primera fuente de malas decisiones.

Criterio 1: la forma real de tus datos

Antes de mirar consistencia o escalabilidad, pregúntate cómo se relacionan tus entidades entre sí.

• Datos con relaciones reales y consultadas con frecuencia (un pedido tiene un cliente, varias líneas, un método de pago, un estado de envío que cambia con el tiempo): esto es el terreno natural del modelo relacional. Vas a necesitar JOINs, y necesitarlos no es una señal de mal diseño sino una consecuencia directa de que los datos están relacionados.
• Documentos autocontenidos que rara vez se relacionan entre sí (un perfil de usuario con preferencias anidadas, un registro de evento, contenido versionado tipo CMS): un modelo de documentos como MongoDB encaja mejor si además cada documento tiene una forma variable.
• Acceso por clave con lecturas y escrituras extremadamente rápidas y sin necesidad de consultas complejas (sesiones, caché, contadores, colas): un almacén clave-valor como Redis es la herramienta correcta, y forzarlo a hacer consultas relacionales complejas es usarlo por el motivo equivocado.
• Relaciones que son en sí mismas el dato interesante (redes sociales, motores de recomendación, detección de fraude por patrones de conexión): una base de datos de grafos como Neo4j modela esto de forma mucho más natural que tablas con múltiples tablas intermedias.

Criterio 2: qué garantía de consistencia necesitas de verdad

Aquí es donde entra el teorema CAP, casi siempre citado mal. La formulación estricta dice que un sistema distribuido no puede garantizar simultáneamente Consistencia, Disponibilidad y Tolerancia a particiones de red; ante una partición de red (que eventualmente ocurre), el sistema tiene que elegir entre seguir respondiendo con el riesgo de servir datos desactualizados (AP) o dejar de responder hasta poder garantizar consistencia (CP). Es importante no forzar esta elección en el diseño: la partición de red no es una opción de configuración, es un evento que ocurre y para el que el sistema ya tiene un comportamiento definido por su arquitectura.

Lo que importa para tu decisión no es la teoría, es esta pregunta: ¿qué pasa en tu negocio si dos usuarios ven temporalmente valores distintos del mismo dato?

• Si la respuesta es “un desastre” (saldo de una cuenta bancaria, stock de un artículo que se vende una sola vez, un cupo de plazas), necesitas consistencia fuerte. Un motor relacional con transacciones ACID —PostgreSQL, MySQL— te la da por diseño en un solo nodo, y con más esfuerzo en clústeres distribuidos.
• Si la respuesta es “no pasa nada, se corrige en segundos” (contador de “me gusta”, un feed que puede tardar un momento en reflejar un cambio, una recomendación), un sistema con consistencia eventual como DynamoDB o Cassandra te da a cambio mucha más disponibilidad y capacidad de escritura distribuida.

Criterio 3: tus patrones de consulta, no solo tu esquema

Un esquema bien modelado en el papel puede ser una mala elección si no encaja con cómo vas a consultarlo en producción.

• ¿Necesitas hacer consultas ad hoc que no puedes prever hoy (analítica interna, paneles de administración con filtros libres, informes)? El SQL declarativo, con su planificador de consultas capaz de optimizar combinaciones que nadie escribió a mano, es muy difícil de igualar. En un modelo de documentos, cada nuevo patrón de acceso que no anticipaste al diseñar el esquema suele obligarte a desnormalizar datos o hacer agregaciones costosas en la aplicación.
• ¿Tus consultas son casi siempre “dame el documento completo por su identificador” o “dame los últimos N eventos de esta clave”? Ahí un modelo de documentos o clave-valor no solo es suficiente, es más rápido: menos indirección, menos coste de unir tablas que nunca vas a necesitar unir.
• ¿Necesitas búsqueda de texto completo, geoespacial o vectorial junto con tus datos transaccionales? PostgreSQL con sus extensiones cubre las tres sin salir del motor, algo que tratamos en detalle en el artículo sobre PostgreSQL en 2026 y en el dedicado a bases de datos vectoriales y pgvector.

Criterio 4: la escalabilidad que necesitas frente a la que crees necesitar

Este es el criterio donde más proyectos se equivocan, casi siempre en la misma dirección: sobrestiman la escala que van a alcanzar y pagan el coste de complejidad de un sistema distribuido desde el día uno.

Un PostgreSQL bien indexado, con una réplica de lectura y un servidor con recursos razonables, sostiene sin esfuerzo la inmensa mayoría de aplicaciones B2B y SaaS de tamaño medio: decenas de miles de usuarios activos, millones de filas por tabla, miles de escrituras por segundo. El punto donde de verdad necesitas un sistema distribuido pensado para escritura horizontal masiva —Cassandra, DynamoDB, Cassandra-compatible ScyllaDB— es un punto de escala que la mayoría de proyectos nunca alcanza, y que cuando se alcanza suele venir acompañado de presupuesto y equipo dedicado a resolverlo.

Los híbridos: la respuesta más común en sistemas reales

En la práctica, la mayoría de arquitecturas maduras en 2026 no son “todo SQL” ni “todo NoSQL”: son PostgreSQL o MySQL como fuente de verdad transaccional, Redis como caché y almacén de sesiones, y ocasionalmente un motor de búsqueda (Elasticsearch, Meilisearch) o una base de datos vectorial para necesidades específicas. Elegir “una base de datos para todo” rara vez es la limitación real; la limitación real suele ser no tener claro qué dato vive en qué sistema y por qué. Este patrón se relaciona directamente con arquitectura de microservicios: cuándo tiene sentido y cuándo es un error, donde la pregunta de “una base de datos por servicio o una compartida” tiene la misma lógica de fondo.

Una checklist para decidir

1. Dibuja las relaciones entre tus entidades. Si hay relaciones reales, empieza por relacional.
2. Define, dato por dato, qué pasa si dos lecturas simultáneas ven valores distintos. Donde la respuesta sea “un problema serio”, exige consistencia fuerte.
3. Lista tus tres patrones de consulta más frecuentes hoy y los que preverías en un año. Si incluyen filtros ad hoc o agregaciones cruzadas, prioriza SQL.
4. Estima tu escala real con números, no con aspiraciones: usuarios activos, escrituras por segundo, tamaño de tabla en un año. Compara esa cifra con lo que un PostgreSQL bien dimensionado sostiene antes de asumir que necesitas algo distribuido.
5. Si el resultado son necesidades mixtas, no elijas un solo sistema: usa el motor relacional como fuente de verdad y añade piezas especializadas (caché, búsqueda, vectores) donde de verdad aporten.

La pregunta que de verdad deberías hacerte no es “SQL o NoSQL”, sino “qué garantías necesita cada uno de mis datos, y qué sistema me las da con menos esfuerzo operativo”. Casi siempre, para el conjunto de datos que sostiene el negocio, esa respuesta sigue siendo un motor relacional.