JSON en bases de datos: cuándo es buena idea y cuándo no

En los últimos años, el uso de campos JSON en bases de datos ha pasado de ser una rareza técnica a convertirse en una práctica habitual. Prácticamente todos los grandes sistemas gestores de bases de datos relacionales —PostgreSQL, MySQL, SQL Server u Oracle— incorporan hoy tipos de datos específicos para JSON, junto con funciones avanzadas de consulta, indexación y manipulación de su contenido.

En PostgreSQL, por ejemplo, conviven dos tipos distintos: JSON, que almacena la representación textual original, y JSONB, un formato binario optimizado que permite indexación y ofrece un rendimiento muy superior en consultas. Esta distinción no es meramente técnica: tiene implicaciones directas en el rendimiento, el almacenamiento y la flexibilidad de las soluciones que se construyen sobre estos datos.

Todo esto ocurre, además, en paralelo al auge de las bases de datos NoSQL y a la adopción generalizada de arquitecturas orientadas a servicios. En este contexto, JSON se ha consolidado como el formato de intercambio de datos por excelencia, especialmente en entornos dominados por APIs y aplicaciones distribuidas.

La combinación de estos factores conduce de forma casi inevitable a una pregunta que aparece con frecuencia tanto en equipos de desarrollo como en debates técnicos:

Si puedo guardar JSON en mi base de datos, ¿por qué no hacerlo siempre?

La duda parece razonable. JSON es flexible, se adapta bien a estructuras cambiantes, encaja de forma natural con las APIs modernas y reduce muchas de las fricciones asociadas a la evolución de los esquemas tradicionales. Sin embargo, esa misma flexibilidad puede convertirse en un problema serio cuando se adopta sin una reflexión previa sobre sus implicaciones técnicas y de diseño.

En Analytics Lane

null y undefined en JavaScript y TypeScript: ¿son realmente lo mismo?

Esta entrada no pretende enfrentar dos bandos ni defender una postura dogmática. El objetivo es mucho más pragmático: analizar en qué contextos el uso de JSON en una base de datos es una buena decisión de diseño y en cuáles introduce complejidad innecesaria, deuda técnica o problemas de mantenimiento a medio y largo plazo. Porque en ingeniería de datos, como en tantas otras áreas, la pregunta clave rara vez es si algo es posible, sino si es conveniente.

¿Qué significa realmente “usar JSON en una base de datos”?

Cuando se habla de “usar JSON en una base de datos”, a menudo se agrupan bajo una misma etiqueta situaciones muy distintas. Sin embargo, no todas tienen las mismas implicaciones ni responden a las mismas decisiones de diseño. Conviene aclarar estas diferencias antes de avanzar.

Modelo complementario: JSON como extensión del esquema

En un primer enfoque, JSON actúa como un contenedor flexible para información secundaria o variable, sin alterar la estructura relacional principal. El esquema sigue estando claramente definido: existen tablas con columnas bien definidas, claves primarias, relaciones entre entidades y restricciones de integridad.

En este contexto, el JSON se utiliza para almacenar aquellos datos que no encajan bien en una estructura rígida o cuya variabilidad no justifica la creación de nuevas tablas. Metadatos, preferencias de usuario o configuraciones opcionales son ejemplos habituales. El modelo relacional sigue siendo el eje central del sistema, y JSON cumple un papel complementario.

Modelo dominante: JSON como almacenamiento principal

En un segundo enfoque, el papel de JSON cambia de forma radical. El modelo relacional se reduce al mínimo y la mayor parte de la información reside dentro de uno o varios campos JSON. El esquema deja de estar explícitamente definido en la base de datos y pasa a estar implícito en el código de la aplicación, en la manera en que los desarrolladores generan, interpretan y validan esos documentos.

Aquí, la base de datos se convierte en un contenedor genérico de documentos, mientras que las reglas del modelo de datos —qué campos existen, cuáles son obligatorios o qué relaciones hay entre ellos— se desplazan a la capa de aplicación.

Aclaración crítica: JSON en SQL no es NoSQL

Existe un malentendido frecuente que conviene despejar: almacenar JSON en una base de datos relacional no la convierte automáticamente en una base de datos NoSQL. Siguen existiendo transacciones ACID, SQL, esquemas, restricciones y mecanismos de consistencia propios del modelo relacional.

Lo que realmente cambia no es la naturaleza del sistema, sino el lugar donde se definen y se hacen cumplir las reglas del modelo de datos: en la base de datos o en la aplicación.

Por qué el uso de JSON en bases de datos resulta tan atractivo

Para entender por qué el uso de JSON en bases de datos se ha popularizado tanto, es necesario reconocer que sus ventajas son reales y, en muchos contextos, se encuentran plenamente justificadas. No se trata de una moda arbitraria, sino de una respuesta práctica a la forma en que hoy se desarrollan y evolucionan las aplicaciones.

Flexibilidad inmediata

Una de las principales razones del atractivo de JSON es la flexibilidad que ofrece desde el primer momento. Permite almacenar estructuras complejas y heterogéneas sin necesidad de modificar el esquema de la base de datos cada vez que aparece un nuevo campo. En proyectos en fases tempranas, donde los requisitos cambian con rapidez y el modelo de datos aún no está madurando, esta característica puede acelerar de forma notable el desarrollo. En entornos como startups o equipos ágiles, donde la velocidad de iteración es crítica, reducir la fricción asociada a los cambios de esquema se convierte en una ventaja decisiva.

Alineación natural con el ecosistema moderno

JSON encaja de forma natural con el ecosistema actual de desarrollo. La mayoría de aplicaciones modernas consumen y producen JSON de forma constante a través de APIs REST u otros mecanismos similares. Al almacenar directamente estas estructuras en la base de datos se evitan transformaciones intermedias y se reduce la fricción entre la capa de aplicación y la capa de persistencia. El modelo de datos que se maneja en el código es, en muchos casos, prácticamente el mismo que se persiste, lo que simplifica el desarrollo y disminuye la probabilidad de errores derivados de conversiones innecesarias.

Evolución sin migraciones complejas

Otro factor clave es la facilidad para evolucionar los datos sin recurrir a migraciones de esquema complejas. Añadir un nuevo atributo a un objeto JSON no requiere alterar tablas ni coordinar despliegues delicados que afecten a todo el sistema. El software puede seguir funcionando mientras los nuevos clientes adoptan gradualmente el nuevo campo. Esta capacidad resulta especialmente atractiva en sistemas que evolucionan de forma continua, donde las migraciones representan riesgos operativos y costes adicionales.

Legibilidad y mantenimiento inicial

Al menos en las primeras etapas de un proyecto, JSON puede ofrecer una mayor sensación de claridad. Un campo JSON bien estructurado permite inspeccionar datos relacionados de forma conjunta, sin necesidad de navegar por múltiples tablas auxiliares. Para un desarrollador que se incorpora al proyecto, visualizar información agrupada lógicamente puede resultar más intuitivo que reconstruir mentalmente un modelo relacional disperso, sobre todo cuando se trata de datos secundarios.

Nota: estos beneficios son reales, pero tienen fecha de caducidad. A medida que los sistemas maduran, muchas de estas ventajas tienden a convertirse en problemas.

Cuándo sí es buena idea usar JSON

Existen escenarios claros en los que el uso de JSON en una base de datos no solo es razonable, sino directamente recomendable. En estos contextos, JSON no actúa como un atajo improvisado, sino como una herramienta adecuada para el tipo de información que se quiere modelar.

Datos semiestructurados e inherentemente variables

Los datos semiestructurados son aquellos que tienen cierta forma, pero cuya estructura exacta puede variar entre registros o cambiar con el tiempo. Este tipo de información suele presentar una gran diversidad y resulta difícil de encajar en un esquema rígido sin introducir complejidad innecesaria.

Ejemplos habituales son los metadatos, los atributos opcionales o los sistemas de etiquetas y clasificaciones. En estos casos, no todos los registros comparten los mismos campos, y forzar su representación mediante columnas fijas suele conducir a tablas llenas de valores nulos o a modelos excesivamente complejos, como los esquemas Entity–Attribute–Value, que además suelen acarrear problemas de rendimiento y mantenimiento.

Aquí, JSON ofrece una solución natural: permite agrupar información variable sin distorsionar el modelo principal ni introducir estructuras artificiales difíciles de justificar.

Preferencias y configuración de usuario

Las preferencias de usuario constituyen otro caso clásico en el que JSON encaja especialmente bien. Este tipo de información suele crecer de forma incremental, cambiar con el tiempo y, en general, no participa en consultas complejas ni agregaciones críticas para el negocio.

Al almacenarlas como JSON se gana flexibilidad para añadir nuevas opciones sin modificar el esquema principal, se limita el impacto de los cambios a la propia aplicación y se mantiene la información cerca del recurso que describe. Todo ello reduce la fricción evolutiva sin comprometer aspectos esenciales del modelo de datos.

Configuración de sistemas

La configuración de sistemas comparte muchas de estas características. Se trata de información que se lee con frecuencia, pero rara vez se consulta de forma analítica. No suele requerir relaciones complejas y, además, cambia con cierta regularidad.

En este contexto, JSON resulta un formato de almacenamiento muy adecuado: es expresivo, flexible y fácil de versionar, y evita la proliferación de tablas dedicadas exclusivamente a parámetros de configuración.

Integración con sistemas externos y arquitecturas de Data Lake

Cuando una aplicación consume APIs de terceros, es habitual querer almacenar las respuestas completas, al menos en una primera fase. En arquitecturas de tipo Data Lake —especialmente en las capas más crudas, como raw o bronze—, JSON es prácticamente la opción natural.

Permite capturar la respuesta de una API sin transformaciones, preservar todos los campos (incluidos aquellos que no se esperaban inicialmente), facilitar reprocesamientos posteriores y actuar como puente entre sistemas heterogéneos. Por ejemplo, si un proveedor externo devuelve documentos con estructura variable, almacenarlos como JSON en una tabla de staging permite que analistas o equipos posteriores exploren los datos sin necesidad de una coordinación inmediata con el equipo de desarrollo.

Event logging y auditoría

Los sistemas de logging y auditoría también se benefician del uso de JSON. Los eventos suelen tener estructuras distintas según su tipo y evolucionan con el tiempo. Almacenar estos registros como JSON permite preservar la información completa de cada evento sin imponer una estructura rígida que limite su expresividad.

Este enfoque resulta especialmente útil cuando los datos se almacenan para análisis posterior, trazabilidad o depuración, más que para consultas transaccionales críticas.

Fases tempranas con el esquema en exploración

En proyectos nuevos, donde el modelo de datos aún no está claramente definido, JSON puede ser una herramienta valiosa para avanzar sin bloquear el desarrollo. Permite experimentar, iterar y aprender sobre la forma real de los datos antes de comprometerse con un esquema definitivo.

Eso sí, esta ventaja tiene fecha de caducidad. A medida que el sistema madura, conviene revisar estas decisiones y consolidar el modelo cuando la incertidumbre disminuye.

Cuándo no es buena idea, aunque funcione

El hecho de que una base de datos permita almacenar y consultar JSON no implica que hacerlo sea siempre una buena decisión. Muchos de los problemas asociados a su uso aparecen precisamente cuando se aplica a contextos para los que no está pensado.

Datos altamente estructurados con significado de negocio

Cuando los datos son altamente estructurados, tienen tipos bien definidos y un significado claro para el negocio, lo natural es que formen parte del modelo relacional. Fechas de transacciones, importes monetarios, estados del negocio o identificadores únicos participan habitualmente en validaciones, filtros, ordenaciones y agregaciones frecuentes.

Encapsular este tipo de información dentro de JSON dificulta estas operaciones y elimina muchas de las garantías que ofrece la base de datos, como la validación de tipos, rangos o formatos. Lo que se gana en flexibilidad se pierde en robustez.

Consultas frecuentes y complejas

Aunque muchos motores de bases de datos permiten indexar campos JSON, hacerlo introduce complejidad tanto técnica como conceptual. Las consultas se vuelven más difíciles de leer, mantener y optimizar, y el código SQL pierde claridad rápidamente.

Por ejemplo, una consulta basada en JSON puede acabar siendo mucho más difícil de entender y mantener que su equivalente relacional:

SELECT id, name, details->>'price' AS price
FROM products
WHERE (details->>'price')::numeric > 1000
  AND details @> '{"brand": "Dell"}'
ORDER BY (details->>'price')::numeric;

Frente a una alternativa relacional mucho más clara:

SELECT id, name, price
FROM products
WHERE price > 1000 AND brand = 'Dell'
ORDER BY price;

Además, el coste de procesar documentos JSON suele ser mayor que el de trabajar con columnas nativas, especialmente cuando se utilizan índices GIN sobre grandes volúmenes de datos.

Integridad referencial crítica

La integridad referencial es uno de los pilares de los modelos relacionales. Las claves foráneas y las restricciones permiten garantizar la coherencia de los datos de forma automática. Al esconder identificadores dentro de JSON, estas garantías desaparecen.

Por ejemplo, si una tabla almacena identificadores de clientes dentro de un campo JSON, nada impide que esos identificadores apunten a registros inexistentes o eliminados. La responsabilidad de mantener la coherencia pasa completamente a la aplicación, aumentando el riesgo de la aparición de inconsistencias difíciles de detectar y corregir.

Impacto en el rendimiento a largo plazo

Parsear y recorrer estructuras JSON tiene un coste que puede ser despreciable en sistemas pequeños, pero que se vuelve significativo a medida que el volumen de datos crece. Los documentos JSON grandes consumen más memoria, generan más I/O y requieren más procesamiento que un conjunto de columnas bien indexadas.

Estos costes suelen aparecer de forma gradual, lo que hace que el problema pase desapercibido hasta que el sistema alcanza cierta escala.

Opacidad y mantenibilidad decreciente

Con el tiempo, un campo JSON grande tiende a convertirse en una caja negra. Resulta cada vez más difícil saber qué estructura tiene exactamente, qué campos son obligatorios, qué variantes existen o cómo está siendo utilizado por las distintas partes de la aplicación.

Lo que en un primer momento parecía una solución flexible y elegante puede acabar convirtiéndose en un obstáculo operativo y en una fuente constante de incertidumbre.

Matriz de decisión rápida

Después de analizar los distintos escenarios, se puede diseñar una tabla sencilla que nos pueda ayudar a decidir por una opción u otra sin tener que entrar en discusiones interminables. Una tabla que no pretende ser una regla absoluta, sino una guía rápida que resume cuándo cada enfoque suele funcionar mejor.

La idea clave es que el modelo relacional brilla cuando hay estructura, reglas claras y uso intensivo de los datos, mientras que JSON resulta útil cuando la variabilidad y la flexibilidad pesan más que las garantías del esquema.

Si varias filas clave caen del lado relacional, probablemente JSON no sea la mejor elección para esos datos, por mucho que “funcione”. Si, en cambio, predominan los factores de variabilidad y exploración, JSON puede ser una solución razonable —al menos durante un tiempo.

El gran error: usar JSON para evitar diseñar

Uno de los usos más problemáticos de JSON aparece cuando se emplea como una forma de evitar tomar decisiones de diseño. Diseñar un modelo de datos implica entender el dominio, identificar qué entidades existen, cómo se relacionan y qué reglas deben cumplirse. Es un proceso que requiere tiempo, criterio y conocimiento del negocio.

JSON ofrece un atajo tentador: guardar toda la información junta, sin pensar demasiado en su estructura, y posponer esas decisiones para “más adelante”. El problema es que ese “más adelante” casi nunca llega.

La ilusión de la flexibilidad

En las primeras etapas, esta estrategia suele funcionar sorprendentemente bien. El documento JSON es pequeño, el equipo es reducido y todos comparten el mismo contexto mental del sistema. Los cambios son rápidos, visibles y fáciles de aplicar. Añadir un nuevo campo parece trivial y no genera fricción.

Con el paso del tiempo, sin embargo, el documento comienza a crecer. Aparecen excepciones, campos opcionales que dejan de serlo, y variantes ligeramente distintas para casos similares. Distintos desarrolladores añaden información según necesidades inmediatas, sin una visión global. Lo que empezó como flexibilidad acaba convirtiéndose en ambigüedad, y nadie puede afirmar con certeza cuál es la estructura “correcta”.

El esquema se traslada, no desaparece

Aquí está el punto más importante: el esquema no desaparece por usar JSON. Simplemente se traslada de la base de datos al código de la aplicación.

Ese esquema implícito suele ser:

• Menos visible, porque no existe una definición centralizada y explícita.
• Menos validable, ya que los errores de estructura o tipo suelen detectarse tarde, a menudo en producción.
• Más difícil de mantener, porque cada desarrollador puede interpretarlo de forma ligeramente distinta.
• Más costoso de cambiar, ya que las suposiciones sobre el formato están repartidas por múltiples capas del sistema.

Cambiar un esquema relacional puede requerir una migración, pero es un proceso explícito y controlado. Cambiar un esquema implícito disperso en el código suele ser más arriesgado y mucho más difícil de auditar.

Validación como paliativo (no como solución)

Para reducir estos problemas, algunos equipos introducen validación mediante JSON Schema. Definir formalmente qué campos existen, qué tipos tienen y cuáles son obligatorios ayuda a imponer cierta disciplina.

{
  "type": "object",
  "properties": {
    "name": { "type": "string" },
    "price": { "type": "number", "minimum": 0 }
  },
  "required": ["name", "price"]
}

Esto es, sin duda, mejor que no validar nada. Sin embargo, sigue siendo un paliativo. La validación depende de que la aplicación la ejecute correctamente en todos los puntos de entrada. No forma parte de las garantías intrínsecas del sistema de base de datos, como ocurre con las restricciones relacionales. Por tanto, JSON Schema complementa el diseño, pero no lo sustituye.

El enfoque híbrido: lo mejor de ambos mundos

En la práctica, la mayoría de sistemas bien diseñados no adoptan posturas extremas. En lugar de elegir entre “todo relacional” o “todo JSON”, optan por un enfoque híbrido, utilizando cada herramienta donde realmente aporta valor.

Los datos estables, críticos y con un significado de negocio claro se modelan de forma relacional, aprovechando plenamente las garantías del sistema: integridad referencial, validación, indexación eficiente y consistencia transaccional.

Los datos secundarios, variables o difíciles de estructurar —como configuraciones, metadatos o payloads externos— se almacenan como JSON, manteniendo la flexibilidad necesaria sin contaminar el núcleo del modelo.

Este equilibrio permite construir sistemas robustos sin renunciar a la adaptabilidad. No se trata de elegir un bando, sino de entender las fortalezas y límites de cada enfoque.

Tabla comparativa: opciones de almacenamiento

La siguiente tabla resume los compromisos más habituales entre los distintos enfoques:

Recomendación: para la mayoría de sistemas actuales, el enfoque híbrido (Relacional + JSON) ofrece el mejor equilibrio entre solidez técnica y flexibilidad evolutiva.

Preguntas clave antes de decidir

Antes de optar por JSON, conviene detenerse y analizar de forma honesta una serie de puntos respecto a los datos que se van a almacenar. No son cuestiones puramente técnicas, sino acerca del uso y contexto del sistema, y suelen dar una visión bastante clara.

Frecuencia y complejidad de consultas

Si un dato va a consultarse con frecuencia, especialmente mediante filtros, ordenaciones o agregaciones, el modelo relacional suele ser claramente superior gracias a sus índices y tipos nativos. Si, por el contrario, se consulta rara vez o se recupera como bloque completo, JSON puede ser suficiente.

Relaciones e integridad

Cuando un dato tiene relaciones claras con otras entidades y la integridad referencial es crítica, el modelo relacional ofrece garantías que JSON no puede proporcionar de forma nativa. Si no existen relaciones o la consistencia puede gestionarse a nivel de aplicación, JSON puede ser aceptable.

Estructura y evolución

Si la estructura es estable y bien conocida, modelarla explícitamente suele simplificar el sistema a largo plazo. Si, en cambio, se espera que cambie con frecuencia o aún se está explorando el dominio, JSON puede ofrecer una flexibilidad inicial valiosa.

Validación y consistencia

Cuando la validación debe imponerse a nivel de base de datos, el modelo relacional es la opción natural. Si la validación puede delegarse en la aplicación y no es crítica, JSON puede funcionar, siempre con disciplina.

Conclusiones

JSON en bases de datos no es una moda pasajera ni un error de diseño por definición. Es una herramienta potente que, bien utilizada, puede simplificar notablemente el desarrollo de aplicaciones modernas. El problema surge cuando se usa como sustituto del diseño en lugar de como complemento.

La pregunta correcta nunca es: “¿se puede guardar algo como JSON?”

La pregunta correcta es: “¿qué se gana y qué se pierde al hacerlo?”

Tener claras esas implicaciones es lo que marca la diferencia entre una solución flexible y robusta y una fuente futura de problemas técnicos y deuda operativa.