PostgREST 14 en pymes: API, roles y auditoria
PostgREST 14 expone PostgreSQL como API REST con roles, JWT y politicas de filas. Guia para publicar datos internos sin perder permisos ni salida.
Una ruta REST puede nacer de una vista SQL, un rol y una politica 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 quien puede leer o cambiar cada registro. La guia explica el flujo, los permisos y la prueba de salida.
Donde aparece la API improvisada
La cifra que ordena la decision 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 que se instalo, que configuracion 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 mas de 180 millones de desarrolladores y 630 millones de repositorios. Una pyme mendocina tiene menos codigo, 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 despues 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 documentacion de autenticacion define una idea concreta: PostgREST autentica el pedido y deja que PostgreSQL autorice la accion. El JWT identifica rol o claims. PostgreSQL aplica GRANT, vistas, funciones y politicas de seguridad por fila. Esa separacion permite cambiar permisos sin tocar cada cliente.
El control tambien 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.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, IT define las tablas que 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 auditoria. Cuarto, se crean roles de lectura, carga y administracion. Quinto, PostgREST recibe una peticion HTTP, valida JWT y ejecuta la consulta con el rol correspondiente. Sexto, Row Level Security filtra filas segun matricula, area o estado. Septimo, logs, backup y monitoreo registran pedidos, errores y restauracion.
PostgREST recibe URL, metodo, headers y token; entrega JSON, codigo HTTP y errores de base. PostgreSQL guarda datos y decide permisos. La documentacion de RLS explica que las politicas filtran filas antes de devolver resultados. El reverse proxy agrega HTTPS, limite de cuerpo y logs de acceso. El backup recupera base, roles, funciones y configuracion; 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. Auditoria lee historicos. Un token vencido rechaza pedidos. Un rol sin GRANT recibe error antes de tocar la tabla.
Que 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 dolar vendedor oficial de $1.412 informado por Bluelytics. Incluye dos vistas, cuatro roles, autenticacion, documentacion de endpoints, pruebas de permisos y restauracion.
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, numero, estado y fecha de alta. Luego se agrega una carga controlada, como un tramite con adjunto en S3 y estado inicial.
Donde se rompe y como probarlo
Primer riesgo: exponer tablas en vez de vistas. La senal 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 senal 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 senal 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, que dato recibe y que queda escrito.