PostgREST 14 en pymes: API, roles y auditoría
PostgREST 14 expone PostgreSQL como API REST con roles, JWT y políticas de filas. Guía para publicar datos internos sin perder permisos ni salida.
Una ruta REST puede nacer de una vista SQL, un rol y una política de filas. PostgREST 14 toma una base PostgreSQL y publica endpoints HTTP donde los permisos viven en la propia base. Para una pyme con sistemas chicos y reportes dispersos, esto reduce scripts sueltos y muestra quién puede leer o cambiar cada registro. La guía explica el flujo, los permisos y la prueba de salida.
Dónde aparece la API improvisada
La cifra que ordena la decisión esta en el release: PostgREST v14.11 fue publicado el 4 de mayo de 2026 y entrega binarios por sistema operativo, incluido Linux estatico. Una API escrita a mano puede crecer sin inventario; un servicio versionado permite saber qué se instalo, que configuración usa y que base expone. El endpoint pegado en un script queda sin dueño. La escala global marca el riesgo de multiplicar integraciones. Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una pyme mendocina tiene menos código, pero igual sufre cuando cada planilla, portal y reporte consulta la base con reglas distintas.
Que parte del permiso queda en la base
El antagonista es el endpoint express que lee con usuario administrador y después filtra en JavaScript. En un colegio profesional de Cuyo con 1.800 matriculados, secretaria puede consultar cuotas, mesa de entradas puede cargar tramites y tesoreria puede ver deuda. Un sello fechador de plastico queda al lado del scanner; el permiso real debe quedar en la base, no en la memoria de quien atiende. La documentación de autenticación define una idea concreta: PostgREST autentica el pedido y deja que PostgreSQL autorice la acción. El JWT identifica rol o claims. PostgreSQL aplica GRANT, vistas, funciones y políticas de seguridad por fila. Esa separacion permite cambiar permisos sin tocar cada cliente. El control también sirve para bajas. Si una persona deja el colegio, se revoca el rol, se corta el token y las rutas dejan de mostrar datos en el mismo punto de entrada.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, IT define las tablas qué se pueden exponer y deja fuera datos sensibles. Segundo, crea vistas para matriculados, pagos, tramites o turnos. Tercero, PostgreSQL 18 guarda registros estructurados, usuarios, estados y auditoría. Cuarto, se crean roles de lectura, carga y administración. Quinto, PostgREST recibe una peticion HTTP, valida JWT y ejecuta la consulta con el rol correspondiente. Sexto, Row Level Security filtra filas segun matrícula, área o estado. Septimo, logs, backup y monitoreo registran pedidos, errores y restauración. PostgREST recibe URL, método, headers y token; entrega JSON, código HTTP y errores de base. PostgreSQL guarda datos y decide permisos. La documentación de RLS explica que las políticas filtran filas antes de devolver resultados. El reverse proxy agrega HTTPS, límite de cuerpo y logs de acceso. El backup recupera base, roles, funciones y configuración; se prueba levantando la API en otro puerto. Los permisos se escriben por rol. Secretaria carga tramites. Tesoreria lee pagos y emite reportes. Matriculados ven sus propios datos. Auditoría lee historicos. Un token vencido rechaza pedidos. Un rol sin GRANT recibe error antes de tocar la tabla.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 18, PostgREST 14.11, reverse proxy HTTPS, JWT emitido por Authentik o Keycloak, logs, monitoreo y backup diario. El piloto cuesta entre USD 1.200 y USD 3.200, entre ARS 1,69 y 4,52 millones al dólar vendedor oficial de $1.412 informado por Bluelytics. Incluye dos vistas, cuatro roles, autenticación, documentación de endpoints, pruebas de permisos y restauración. El plazo va de tres a cinco semanas. UMSA suele pedir un entregable verificable: endpoint de consulta, endpoint de carga, token vencido, usuario sin permiso, log descargable, backup restaurado y contrato JSON escrito. El costo no incluye redisenar la base completa ni migrar clientes viejos. El primer entregable debe ser una consulta de bajo riesgo. Por ejemplo, matriculados activos con nombre, número, estado y fecha de alta. Luego se agrega una carga controlada, como un tramite con adjunto en S3 y estado inicial.
Dónde se rompe y cómo probarlo Primer riesgo: exponer tablas en vez de vistas.
La señal aparece cuando un cliente recibe columnas internas. La prueba consulta cada endpoint con un token de menor permiso y revisa campos. Segundo riesgo: RLS incompleta. La señal es un matriculado leyendo registros de otro. La prueba crea dos usuarios y cruza consultas con datos conocidos. Tercer riesgo: JWT sin vencimiento corto. La señal es un token viejo que sigue entrando. La prueba fuerza expiracion y confirma rechazo. Cuarto riesgo: backup sin roles ni funciones. La prueba restaura en una base nueva, levanta PostgREST y ejecuta lecturas, cargas y rechazos. Una API util deja claro quien pregunta, qué dato recibe y que queda escrito.