Compatibilidad PostgREST: qué cubre y alternativas

PostgREST es un servidor web autónomo que transforma una base de datos PostgreSQL existente en una API REST, directamente desde su esquema. No hay una capa de aplicación que escribir: tablas, vistas y funciones se convierten en rutas, y los permisos SQL (roles, políticas RLS) se convierten en la capa de autorización.

En concreto, PostgREST cubre cinco capacidades que surgen en casi todas las evaluaciones:

• Filtrado horizontal: alrededor de treinta operadores (eq, gt, like, ilike, in, is, cs, ov, fts...) directamente en la cadena de consulta.
• Filtrado vertical e incrustación — ?select= proyecta columnas e incrusta relaciones mediante clave externa, por ejemplo customer:customers(email).
• RPC: un POST /rpc/{fonction} llama directamente a una función SQL, que se convierte en un punto final.
• RLS impulsado por JWT: PostgREST cambia el rol activo de Postgres según el token recibido (SET LOCAL ROLE), por lo que sus políticas se aplican tal cual, sin lógica de autorización duplicada en el lado de la aplicación.
• OpenAPI autogenerada: la especificación se deduce del esquema expuesto, sin un archivo que mantener a mano.

curl "https://<gateway>/v1/db/<project_id>/orders \
  ?select=id,total,customer:customers(email) \
  &status=eq.paid \
  &order=created_at.desc" \
  -H "apikey: <votre-cle-api>"

Una única solicitud HTTP filtra los pedidos pagados, incorpora el correo electrónico del cliente mediante una clave externa y ordena por fecha, sin tener que escribir una única ruta a mano.

El RPC sigue la misma lógica: una función SQL ya escrita en su base de datos se convierte en un punto final POST, con sus argumentos pasados en JSON.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/monthly_revenue" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"year": 2026, "month": 8}'

Este principio (el esquema de Postgres es la única fuente de verdad de la API) es lo que hace que PostgREST sea predecible: cada cambio de comportamiento pasa por una migración de SQL, nunca a través de una capa de aplicación separada que podría derivar del esquema real. El proyecto es de código abierto, desarrollado en GitHub, independiente de cualquier proveedor de BaaS en particular.

PostgREST resuelve la capa CRUD. No resuelve el resto del backend de una aplicación. Cuatro deficiencias ocurren sistemáticamente entre los equipos que lo adoptan solos.

• Autenticación: sin emisión de JWT ni gestión de usuarios integrada. Debe compilarlo en SQL o delegarlo a un servicio externo.
• Almacenamiento de archivos — ninguno. Queda por conectar por separado un cubo S3 o equivalente.
• Tiempo real: PostgREST responde a solicitudes HTTP únicas, no envía ningún evento.
• Grupo de conexiones: el propio PostgREST se conecta a Postgres, pero no integra ningún grupo avanzado. A escala, administrarlo se convierte en una decisión operativa en sí misma: un pooler en modo de transacción clásico entra en conflicto con el mecanismo de recarga del esquema PostgREST (vea a continuación cómo Aurabase resuelve este compromiso).

Una consecuencia práctica merece quedar claramente establecida: sin autenticación, sus políticas RLS se convierten en el único límite de seguridad entre un cliente anónimo y sus datos. Una política mal redactada sobre el rol anon no se ve superada por una capa de aplicación adicional: no existe ninguna.

En un proyecto de motor Aurabase Postgres (el motor predeterminado), la puerta de enlace enruta cada solicitud CRUD directamente a una instancia PostgREST v12.2.8 dedicada a este proyecto, dos réplicas, ubicadas junto con el clúster Postgres del inquilino. Esta no es una compatibilidad aproximada: es el binario ascendente de PostgREST en sí, con los mismos operadores, la misma incrustación, el mismo RPC, el mismo RLS impulsado por JWT.

En un proyecto de motor MongoDB, la historia es diferente. MongoDB no tiene equivalente a PostgREST: estas solicitudes se enrutan a un servicio interno de Aurabase, que reimplementa un subconjunto de las mismas convenciones (nombres de operador idénticos, sintaxis ?select= con incrustación, encabezados Prefer y Content-Range) pero en un motor de documentos, no relacional. Esta capa tiene sus propias limitaciones: una incrustación solicitada en la representación devuelta por una mutación se niega explícitamente en lugar de ignorarse silenciosamente, y no existe una ruta RPC equivalente a las funciones SQL.

Un detalle técnico contrasta con la intuición: cada instancia de PostgREST dedicada permanece conectada directamente al Postgres principal, sin pasar por el pooler PgBouncer implementado para este inquilino. Razón supuesta: el modo de agrupación de transacciones interrumpiría la recarga del esquema PostgREST, que se basa en LISTEN/NOTIFY, una conexión persistente, incompatible con un grupo que recicla la conexión para cada transacción.

Otro detalle útil en producción: un proyecto inactivo se puede pausar para ahorrar recursos. La primera solicitud en un proyecto inactivo activa su activación y recibe un 503 con un retraso de reintento, el tiempo para que la instancia dedicada de PostgREST vuelva a funcionar: un compromiso supuesto entre costo y latencia en frío, no un incidente oculto.

PostgREST tiene un uso claro: el esquema de Postgres es la fuente de verdad y el equipo quiere evitar escribir una capa CRUD a mano. Aparte de este caso específico, existen varias familias de alternativas dependiendo de lo que desee agregar: desde nada en absoluto (simplemente autohospedado) hasta un backend completo listo para usar.

La siguiente tabla compara lo que cada opción cubre de forma nativa y lo que deja explícitamente a usted, sin emitir juicios de valor sobre la arquitectura elegida para cada proyecto.

Un punto que a menudo se subestima al elegir "autohospedado": PostgREST en sí sigue siendo liviano de ejecutar, pero la operación de producción (actualización de versión, alta disponibilidad, asociación con un pooler, monitoreo) sigue siendo enteramente su responsabilidad: es este trabajo operativo, no el software, lo que absorben las plataformas administradas.

Para obtener una comparación detallada entre los enfoques GraphQL (pg_graphql, Hasura y PostGraphile), consulte nuestro artículo dedicado a la API GraphQL en Postgres.

Cuatro situaciones surgen con mayor frecuencia. La elección correcta depende principalmente de lo que esté dispuesto a montar y mantener usted mismo.

• Solo desea una API REST sobre un esquema de Postgres existente, nada más. PostgREST autohospedado es suficiente: hace exactamente lo que hace y no es necesario instalar nada más.
• Necesita autenticación, almacenamiento y tiempo real adicionales, y está listo para ensamblar varios servicios. Supabase, o PostgREST acompañado de su propia pila de aplicaciones, satisface esta necesidad.
• Prefieres GraphQL a REST. Hasura o PostGraphile cubren este terreno: una elección arquitectónica diferente, no un reemplazo directo de PostgREST.
• Quiere un backend completo de Postgres sin unir múltiples servicios separados. Este es el ángulo que documenta nuestra arquitectura Rust unificada : PostgREST real para la capa CRUD, rodeado de forma nativa por funciones de autenticación, almacenamiento, tiempo real y de borde.