PostgreSQL JSONB vs columnas normales: cuándo conviene cada opción
Publicado el 2026-10-26 por frfrand
Modelado SQL y consultas a campos flexibles sin perder rendimiento
En una API es tentador guardar todo un objeto JSON en una columna y olvidarse del esquema. PostgreSQL permite usar JSONB y es muy útil, pero cuando cada consulta empieza a filtrar dentro de documentos enormes tal vez convenga replantearlo.
La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.
Qué hace JSONB vs columnas normales
JSONB almacena documentos binarios consultables e indexables, con operadores específicos. Las columnas relacionales ofrecen tipos, claves y restricciones más directas para datos que siempre necesitás filtrar, relacionar o agregar. No es una elección absoluta; pueden coexistir.
No alcanza con repetir una receta si no entendés quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.
Un ejemplo concreto
CREATE TABLE eventos (
id bigserial PRIMARY KEY,
cliente_id bigint NOT NULL,
tipo text NOT NULL,
metadata jsonb NOT NULL DEFAULT '{}'::jsonb
);
SELECT id, metadata->>'origen'
FROM eventos
WHERE tipo = 'reserva' AND metadata @> '{"origen":"web"}';
-- Evaluar índices según las consultas realesLos nombres, tablas y claves de este ejemplo son ilustrativos. Probalo primero en una base o entorno de ensayo y adaptá permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.
Paso a paso
- Identifica campos estables del negocio como cliente, fecha, importe y estado.
- Pon esos campos en columnas tipadas cuando necesites restricciones y joins.
- Usa JSONB para metadatos flexibles que cambian entre eventos.
- Mide consultas reales con
EXPLAIN, y añade índices adecuados solo cuando ayuden. - Documenta formato y validaciones del JSON para no terminar con cien variantes incompatibles.
Al final no te quedes con «el SQL no dio error». Comprueba el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que solo aparecen cuando dos usuarios hacen algo a la vez.
Ejemplo de proyecto de trabajo
Una plataforma de reservas guarda cliente_id, horario_id y estado como columnas, y usa JSONB para atributos opcionales de origen de campaña o preferencias. Así no sacrifica integridad de reservas por flexibilidad.
Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.
El error típico
JSONB no reemplaza automáticamente claves foráneas y restricciones sobre todo el documento. Tampoco todas las consultas con JSONB se vuelven rápidas porque exista un índice GIN.
También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guarda una copia verificable o migración reversible y comprueba que la aplicación pueda seguir funcionando durante el cambio.
¿Cómo lo resolvería con ArduMaker?
Cuando administras PostgreSQL en ArduMaker, mezclar tipos SQL y JSONB con criterio te permite adaptar la base sin sacrificar consultas frecuentes de la API.
ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.
Tres comprobaciones antes de publicar
Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?
Seguridad: ¿un usuario autenticado puede acceder solo a su información, y la API utiliza una identidad de base con permisos mínimos?
Recuperación: ¿sabes restaurar los datos y revertir la versión de código compatible si una actualización sale mal?
Si puedes responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando solo miraste si el endpoint devolvía 200.
Recursos para profundizar
Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.