PostGIS multiusuario: permisos, esquemas y edición concurrente
Separe propietarios, editores y lectores, y pruebe conflictos antes de abrir la base a varios clientes.
Revisión editorial: 2026-09-23
Compartir una contraseña entre analistas impide revocar acceso individual y dificulta atribuir cambios. Diseñe grupos de permisos y cuentas personales o de servicio separadas. El propietario de una tabla no debe ser la cuenta con la que un visor público se conecta diariamente.
Un laboratorio de roles
En una base de pruebas administrada por usted, este ejemplo crea un esquema privado, una tabla sintética y dos roles sin capacidad de iniciar sesión. No lo ejecute con nombres existentes ni en producción.
CREATE ROLE gis_demo_reader NOLOGIN;
CREATE ROLE gis_demo_editor NOLOGIN;
CREATE SCHEMA access_lab;
CREATE TABLE access_lab.assets (
id bigint PRIMARY KEY, name text NOT NULL,
revision integer NOT NULL DEFAULT 1
);
INSERT INTO access_lab.assets VALUES (1, 'Synthetic asset', 1);
GRANT USAGE ON SCHEMA access_lab TO gis_demo_reader, gis_demo_editor;
GRANT SELECT ON access_lab.assets TO gis_demo_reader, gis_demo_editor;
GRANT UPDATE (name, revision) ON access_lab.assets TO gis_demo_editor;
Asigne estos roles a cuentas de prueba mediante el administrador. El lector debe consultar y recibir rechazo al editar; el editor puede cambiar los campos autorizados pero no borrar la tabla. Pruebe los permisos con la cuenta efectiva, no con el superusuario que creó el ejemplo.
Evite sobrescribir cambios sin advertencia
La concurrencia necesita una regla de producto: bloquear, detectar conflicto o fusionar. Un patrón de control optimista actualiza únicamente si la revisión leída sigue vigente:
UPDATE access_lab.assets
SET name = 'Reviewed synthetic asset', revision = revision + 1
WHERE id = 1 AND revision = 1
RETURNING id, revision;
La primera ejecución devuelve revisión 2. Una repetición con revisión 1 devuelve cero filas; el cliente debe mostrar un conflicto y recargar, no informar éxito. Este patrón solo funciona si todos los escritores lo respetan o la base aplica una política equivalente. No se activa automáticamente al conectar QGIS.
Permisos de objetos futuros
Los permisos de tablas existentes no cubren necesariamente las nuevas. Configure privilegios predeterminados para el rol que realmente crea objetos y compruebe secuencias, vistas y funciones. Limite el search_path y las conexiones a esquemas previstos. Las vistas públicas deben excluir atributos privados antes de llegar al servidor de mapas.
Pruebas antes del despliegue
Abra dos sesiones, lea la misma revisión y guarde cambios incompatibles. Compruebe la respuesta al segundo guardado, la reversión de una transacción fallida y la revocación de una cuenta. Registre el nivel de aislamiento y los bloqueos esperados. PostgreSQL aporta transacciones y control de acceso; no reproduce automáticamente el versionamiento de una geodatabase empresarial de Esri. Si ese flujo es crítico, debe conservarse o reconstruirse con criterios explícitos.
Relacionar permisos con operaciones concretas
Escribe una matriz antes de otorgar acceso. Quien modifica nombres de activos no necesariamente debe eliminarlos, alterar esquemas o aprobar revisiones. Un publicador puede requerir solo una vista. Un cargador de migración necesita permisos intermedios temporales que no deberían volverse acceso operacional permanente.
| Identidad | Lectura | Escritura | Administración |
|---|---|---|---|
| Servicio público | Vista autorizada | Ninguna | Ninguna |
| Editor de activos | Campos operacionales asignados | Campos explícitos | Ninguna |
| Revisor | Evidencia necesaria | Decisiones por el mecanismo acordado | Ninguna |
| Propietario de esquema | Necesaria para administrar | Cambios estructurales | Mantenimiento controlado |
Usa identidades separadas para atribuir y revocar, con roles de grupo. Comprueba permisos efectivos desde esas identidades. Probar como propietario puede ocultar permisos faltantes o excesivos.
Entender permisos de objetos futuros
Los privilegios predeterminados corresponden al rol creador. Configurarlos para un administrador no afecta automáticamente tablas creadas por otro rol de despliegue. En un laboratorio donde exista gis_owner, un administrador autorizado podría ejecutar:
ALTER DEFAULT PRIVILEGES FOR ROLE gis_owner IN SCHEMA access_lab
GRANT SELECT ON TABLES TO gis_demo_reader;
Esto no concede acceso a tablas existentes y sigue requiriendo uso del esquema. Crea una tabla desechable como gis_owner, consúltala como lector y confirma que actualizar falla. Repite con secuencias o funciones únicamente si el flujo las requiere. No otorgues permisos amplios solo para eliminar un error sin entenderlo.
Ensayar dos escritores con resultados explícitos
- Dos sesiones leen el activo 1 en revisión 1.
- A actualiza el nombre con revisión 1 y confirma, recibiendo revisión 2.
- B envía otro nombre con revisión 1 y recibe cero filas actualizadas.
- El cliente muestra el registro actual y la propuesta del usuario para resolver deliberadamente.
- El nuevo intento usa la revisión recién leída; la aplicación no reintenta silenciosamente sobre el cambio ajeno.
El patrón SQL solo sirve si el punto de escritura real lo aplica. La edición genérica de escritorio no agrega automáticamente el predicado de revisión. Si QGIS escribe directamente, comprueba el comportamiento y decide si necesitas servicio controlado, triggers diseñados u otro mecanismo probado. Es trabajo de integración, no una casilla denominada “PostGIS soporta concurrencia”.
Separar auditoría y prevención de conflictos
Un historial puede explicar una actualización perdida sin evitarla. Un control de conflictos puede rechazar una edición vieja sin identificar a su autor. Define ambas necesidades. Conserva historia proporcional a la tarea y controla datos personales. No atribuyas personas a partir de una cuenta compartida.
Para aprobaciones, separa geometría propuesta y resultado revisado. Un campo de estado no demuestra separación de responsabilidades si los permisos no la aplican. Prueba revocación y reconexión; las sesiones ya abiertas pueden necesitar una respuesta operacional.
Fallos que conviene descubrir temprano
Un lector actualiza mediante una función; una tabla nueva queda pública; un editor modifica la clave de relación; una transacción fallida deja el cliente bloqueado; una edición antigua aparece como exitosa. Incluye esos casos negativos. La guía de recuperación trata la restauración después de un cambio válido pero no deseado.
Referencias: privilegios PostgreSQL, privilegios predeterminados y aislamiento.
Fuentes y documentación
Siguiente paso
Continúe en la colección Open GIS. Para comparar un proyecto concreto, use la calculadora de costo total y solicite una evaluación.