CAPÍTULO 8 · La base de datos también tiene fronteras
Probar no debe significar tocar los datos de los usuarios
Las cuentas empiezan a expresar responsabilidades, pero el equipo necesita un lugar donde ensayar modelos, migraciones y consultas. Si una prueba se conecta a producción, incluso una operación válida para ese usuario puede ser incorrecta para el propósito del trabajo. El problema no es solo cuánto permiso tiene la cuenta, sino sobre qué datos lo ejerce.
Separamos desarrollo, preparación de entregas y producción según las necesidades del proyecto. Cada destino tiene credenciales y configuración identificables. Los datos de prueba deben permitir aprender y verificar sin convertir información real en material de experimentación. Esta decisión completa la separación de entornos que comenzó dentro de config.
Ya podemos ensayar cambios en un contexto propio. Sin embargo, cada migración crea o modifica objetos cuyo propietario y permisos también importan. Una cuenta runtime que hoy funciona puede perder acceso a una tabla nueva si no definimos cómo se heredan los privilegios durante la evolución del esquema.
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
Trabajar en compartimentos separados
Cada carril muestra un ámbito distinto. Compara sus responsabilidades antes de unir sus configuraciones.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- DEV. Cuenta y datos de prueba
- Base DEV. Objetos de su desarrollador
- PROD. Cuenta de runtime separada
- Base PROD. CONNECT y permisos acotados
01 / EL PROBLEMA
¿Para qué sirve?
Un .env local apuntado por error a producción no debería permitir un flush o una migración destructiva con la cuenta del desarrollador.
02 / COMPRENDER
El concepto, explicado
Una base por entorno o desarrollador reduce cruces accidentales, pero las bases en un mismo servidor comparten roles y recursos. Un servidor separado ofrece un límite de aislamiento distinto para producción crítica.
Los permisos son acumulativos. Revocar CONNECT a una persona no anula CONNECT recibido por PUBLIC o por otra membresía. Tampoco cierra conexiones existentes.
En una base nueva diseña permisos de PUBLIC y esquema antes de operar. En una base ya utilizada, inventaría consumidores y prepara los GRANT necesarios antes de revocar; evita bloquear servicios legítimos.
Para conectar hacen falta red, autenticación y CONNECT; para usar objetos, USAGE del esquema y privilegios del objeto. Los valores históricos del esquema public pueden variar por versión y bases actualizadas.
03 / CONSTRUIR
Implementación paso a paso
- Decide aislamiento por servidor y por base según criticidad.
- Crea bases DEV propiedad de su desarrollador sin darle CREATEDB permanente.
- En cada base revisa permisos de PUBLIC, esquema y roles heredados.
- Concede CONNECT solo a las identidades necesarias y USAGE/CREATE según responsabilidad.
- Separa settings y secretos; no copies credenciales productivas a equipos locales.
- Prueba desde una nueva conexión que DEV no entra a PROD.
04 / APLICAR
Ejemplo en SensorHub
-- Provisión en un servidor de laboratorio, con administrador autorizado.
CREATE ROLE sh_dev_ana LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE;
CREATE DATABASE sh_dev_ana OWNER sh_dev_ana;
CREATE DATABASE sh_prod OWNER sh_migrator;
\connect sh_dev_ana
REVOKE CONNECT ON DATABASE sh_dev_ana FROM PUBLIC;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
GRANT USAGE, CREATE ON SCHEMA public TO sh_dev_ana;
\connect sh_prod
REVOKE CONNECT, TEMPORARY ON DATABASE sh_prod FROM PUBLIC;
REVOKE CREATE ON SCHEMA public FROM PUBLIC;
GRANT CONNECT ON DATABASE sh_prod TO sh_app, sh_migrator, sh_readonly;
GRANT USAGE ON SCHEMA public TO sh_app, sh_readonly;
GRANT USAGE, CREATE ON SCHEMA public TO sh_migrator;
-- Audita también grants previos y membresías; este esquema no los elimina.Cómo leer el ejemplo
- CREATE DATABASE no se ejecuta dentro de una transacción; las dos bases son nuevas.
- El código depende de los roles creados en el tema anterior y de los privilegios del administrador del servicio.
- TEMPORARY se concede solo si una tarea lo requiere; retirarlo puede afectar consultas que crean temporales explícitos.
- No es una receta para revocar permisos en producción sin revisar consumidores.
Error habitual
Confundir ver el nombre de una base con poder entrar, o revocar solo un GRANT directo mientras PUBLIC mantiene acceso.
05 / PRACTICAR
Tu turno
Ana no tiene GRANT CONNECT directo, pero puede entrar a sh_prod. Investiga las rutas de permiso.
Ver solución orientativa
Comprueba PUBLIC, membresías, propiedad y privilegios elevados. Corrige la fuente que concede acceso y vuelve a probar en sesión nueva; revisa si las sesiones anteriores requieren cierre.
06 / VERIFICAR
Cómo sabes que funciona
- La nueva conexión DEV a PROD falla.
- El runtime conecta y consulta lo necesario.
- Cada configuración apunta a su base y usuario.
- Se conserva un inventario de consumidores.
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:
Migraciones y permisos para tablas futuras →Continuar en modo relato