CAPÍTULO 8 · La base de datos también tiene fronteras
Las tablas nuevas también deben obedecer el acuerdo
El primer conjunto de tablas puede quedar bien configurado y aun así el siguiente despliegue introducir una diferencia. Las migraciones crean objetos bajo una identidad concreta. Si sus permisos no están coordinados con la cuenta web, el servicio puede arrancar y fallar al utilizar una funcionalidad recién incorporada.
Revisamos propiedad, privilegios sobre objetos existentes y reglas para objetos futuros. La cuenta migradora debe poder evolucionar el esquema sin que eso obligue a conceder ese mismo poder al runtime. Esta revisión convierte los permisos en parte del proceso de entrega y evita tratarlos como un ajuste manual que alguien recuerda después del error.
Con el esquema preparado para cambiar, falta resolver cómo lo administrarán las personas del equipo en su trabajo cotidiano. Una herramienta gráfica puede facilitar esa tarea, pero no debe convertirse en una excepción a las mismas restricciones que acabamos de diseñar.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Quien crea define permisos futuros
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Rol migrador. Creador efectivo de objetos
- Defaults. Reglas para objetos futuros
- Nueva tabla. Recibe ACL al crearse
- Runtime / lector. Prueban permisos concedidos
01 / EL PROBLEMA
¿Para qué sirve?
La aplicación puede funcionar hoy y fallar con permission denied después de una migración si los nuevos objetos no reciben los permisos previstos.
02 / COMPRENDER
El concepto, explicado
GRANT ON ALL TABLES configura objetos existentes, no futuros. ALTER DEFAULT PRIVILEGES configura los creados después por un rol específico, en la base y esquemas indicados.
Los defaults pertenecen al rol efectivo que crea objetos; no se heredan de sus grupos al crear una tabla. Si la migración crea como otro usuario, los defaults de sh_migrator no se aplican.
Django migrate puede crear, alterar y ejecutar cambios de datos. El migrador necesita facultades de propiedad sobre objetos existentes y permisos pertinentes, no solo CREATE en el esquema.
El job de migración recibe credenciales separadas y comprueba destino antes de ejecutarse. No hace falta cambiar al runtime a la cuenta migradora: cada proceso puede tener su configuración y secreto.
03 / CONSTRUIR
Implementación paso a paso
- Inspecciona propietarios de tablas/secuencias existentes y evita cambios masivos indiscriminados.
- Elige un rol efectivo estable para crear y alterar objetos.
- Concede permisos de objetos existentes y define defaults del creador.
- Ejecuta migrate --plan y confirma base, usuario y estrategia de recuperación.
- Aplica la migración desde el job controlado y verifica objetos nuevos.
- Prueba runtime y lector con conexiones propias; revisa django_migrations también.
04 / APLICAR
Ejemplo en SensorHub
-- Conectado a sh_prod como propietario autorizado de estos objetos.
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA public TO sh_app;
GRANT USAGE ON ALL SEQUENCES IN SCHEMA public TO sh_app;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO sh_readonly;
ALTER DEFAULT PRIVILEGES FOR ROLE sh_migrator IN SCHEMA public
GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO sh_app;
ALTER DEFAULT PRIVILEGES FOR ROLE sh_migrator IN SCHEMA public
GRANT USAGE ON SEQUENCES TO sh_app;
ALTER DEFAULT PRIVILEGES FOR ROLE sh_migrator IN SCHEMA public
GRANT SELECT ON TABLES TO sh_readonly;
-- En psql inspecciona lo definido:
\ddp
\dp public.*
SELECT session_user, current_user, current_database();Cómo leer el ejemplo
- ALL TABLES es apropiado solo si el esquema contiene exclusivamente objetos que esos roles deben usar; de otro modo enumera objetos o usa vistas.
- USAGE de secuencias permite generar IDs; no otorga setval. Otorga capacidades adicionales solo si el runtime realmente las necesita.
- No se da USAGE de secuencias al lector en este diseño.
- Defaults no resuelven propiedad incorrecta de tablas antiguas.
Error habitual
Ejecutar migraciones como administrador y esperar que se apliquen defaults configurados para sh_migrator.
05 / PRACTICAR
Tu turno
Agrega una tabla con ID generado en una migración de laboratorio y comprueba inserción por runtime y consulta por soporte.
Ver solución orientativa
Crea como sh_migrator; verifica owner y ACL. sh_app puede INSERT y generar ID; sh_support consulta por su rol lector, pero UPDATE/CREATE fallan. Si creó otro rol, corrige la política del creador y los grants existentes.
06 / VERIFICAR
Cómo sabes que funciona
- Objetos nuevos tienen propietario esperado.
- Runtime funciona sin credencial de migración.
- Los defaults se inspeccionan en la base correcta.
- Lector no puede avanzar secuencias mediante nextval.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
pgAdmin y acceso temporal verificable →Continuar en modo relato