pg_graphql frente a Hasura y PostGraphile en Postgres

pg_graphql realiza una introspección de su esquema SQL y genera un esquema GraphQL que cumple con la convención de retransmisión: <table>Collection, edges, node, filtra por tipo de columna, paginación por cursor. No es necesario escribir ni mantener SDL a mano: el esquema GraphQL sigue su esquema de Postgres.

El punto que importa para la arquitectura: este generador de esquemas vive dentro de la base de datos, como una función SQL, no como un proceso HTTP junto a ella. Aurabase fija la versión 1.6.1 de la extensión (lanzada el 7 de mayo de 2026) en su imagen de Postgres, el mismo paquete oficial .deb distribuido por Supabase. Se instala tanto en el clúster compartido como en las instancias dedicadas de Postgres.

Si vienes de Supabase, donde pg_graphql ha estado habilitado de forma nativa durante mucho tiempo, la lógica te resultará familiar. Nuestra comparación detallada de y nuestra guía de migración cubren el resto del esquema y las políticas de RLS, que siguen siendo los mismos.

Ninguno de los dos competidores históricos de “GraphQL instantáneo en Postgres” ha desaparecido. Su posición ha cambiado y un artículo actualizado debería reflejar eso en lugar de citar la situación de hace dos años.

Hasura publicó una publicación en junio de 2025 con el título explícito, “De GraphQL a PromptQL: comienza un nuevo capítulo”, firmado por su cofundador Tanmai Gopal. El mensaje: la empresa está reorientando su hoja de ruta en PromptQL, una capa de acceso a datos diseñada para agentes de IA. El motor GraphQL no se elimina (la página de inicio de Hasura todavía lo presenta como "probado en batalla"), pero ya no es el mensaje prioritario.

PostGraphile, por su parte, hizo todo lo contrario. Su versión 5, en desarrollo desde 2023 en forma de betas, estuvo disponible de forma generalizada el 24 de marzo de 2026, con un nuevo motor de planificación de consultas llamado Grafast. Este no es un proyecto que esté perdiendo fuerza: la última versión, 5.1.4, data del 5 de agosto de 2026. El paquete npm contó 119.230 descargas solo en la semana del 16 al 22 de agosto de 2026 (registro npm, consultado el 23 de agosto de 2026).

La diferencia que estructura todo lo demás (costo operativo, superficie de ataque, latencia) es dónde se ejecuta el motor GraphQL.

Para ser honesto: PostGraphile también delega la autorización a Postgres a través de pgSettings y el cambio de roles; el RLS nativo no es exclusivo de pg_graphql. Lo que sigue siendo diferente es quién aloja y configura este puente: en PostGraphile, eres tú; En Aurabase esto ya está hecho.

La activación es voluntaria, por proyecto y está reservada para proyectos del motor Postgres: un proyecto MongoDB rechaza la solicitud (GRAPHQL_UNSUPPORTED_ENGINE), siendo pg_graphql una extensión de Postgres sin equivalente en el otro motor.

A través de la CLI o llamando directamente al plan de gestión:

# Idempotente: recordar un proyecto ya activado no recrea nada
aura projects graphql-enable <project_id>

# Equivalente HTTP (plano de gestión, consola JWT)
curl -X POST "$AURA_CONTROL_URL/v1/control/projects/$PROJECT_ID/graphql/enable" \
  -H "Authorization: Bearer $CONSOLE_JWT"

En el lado del servidor, la llamada ejecuta un trabajo graphql_enable que el aprovisionador ejecuta en una sola transacción: instalación de la extensión, creación de la función graphql() en su esquema, GRANTS a los roles de la aplicación. Si un paso falla, todo se cancela: nunca se instala un contenedor a mitad de camino y graphql_enabled solo pasa a true después de un éxito total.

Funciona tanto en el clúster de Postgres compartido como en una instancia CNPG dedicada por proyecto: dos imágenes de Postgres diferentes, pero el mismo mecanismo de extensión. En instancias dedicadas, la extensión se instala a través del manifiesto declarativo del operador CNPG en lugar de SQL directo (una corrección reciente). Un clúster dedicado se ejecuta sin acceso de superusuario a la aplicación y pg_graphql requiere precisamente este privilegio para su CREATE EXTENSION.

Desde Studio, el mismo flujo pasa por la pestaña Configuración de tabla. Un botón allí activa la extensión a nivel de proyecto: la misma llamada HTTP que la anterior, con sondeo hasta la convergencia. Luego, un segundo control establece una directiva @graphql por tabla, para activar o no totalCount y los campos de agregación en su colección GraphQL, sin salir del editor.

Vista de comando único: activación → trabajo de aprovisionamiento subproceso (idempotente, no operativo si ya está en ejecución) → transacción DDL (extensión, función contenedora, GRANT) → indicador graphql_enabled establecido solo después de un éxito total → solicitudes posibles a través de /rpc/graphql.

La función establecida por Aurabase es SECURITY INVOKER: comportamiento predeterminado de Postgres, explicado para que una futura refactorización no lo cambie por accidente. Se ejecuta con los privilegios de la persona que llama (aura_anon, aura_authenticated o aura_service_role, según el reclamo JWT), por lo que sus políticas RLS se aplican exactamente como para una solicitud REST.

En Hasura, la arquitectura es diferente por construcción: el motor convierte cada consulta GraphQL en una consulta SQL restringida por reglas de permiso específicas de Hasura. Estas reglas se definen por rol y por tabla en su propia capa: un sistema paralelo al RLS de Postgres, no una delegación del mismo. Dos lugares para auditar las reglas de acceso, en lugar de solo uno.

La introspección ({ __schema { ... } }) permanece deshabilitada de forma predeterminada en cada proyecto de Aurabase, una postura consistente con el resto de la plataforma. Se puede activar mediante esquema a través de COMMENT ON SCHEMA si una herramienta como Apollo Studio o Graphql-codegen lo necesita.

Una vez graphql_enabled a true, no aparece ninguna ruta /graphql dedicada en la puerta de enlace. La solicitud pasa por el proxy RPC genérico , como cualquier función de Postgres llamada desde el SDK.

curl -X POST "$AURA_URL/v1/db/$PROJECT_ID/rpc/graphql" \
  -H "apikey: $AURA_ANON_KEY" -H "Authorization: Bearer $JWT" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { postsCollection(first: 10, filter: { published: { eq: true } }) { edges { node { id title created_at } } } }"}'

La respuesta sigue la especificación GraphQL ({ data, errors }) sin ajuste adicional de Aurabase: la puerta de enlace detecta que el RPC objetivo es graphql y no lo vuelve a ajustar, a diferencia de un RPC normal. Un cliente GraphQL estándar (Apollo, urql, graphql-request) consume la salida tal cual.

Se establecen dos configuraciones de forma predeterminada tras la activación, a través de una directiva @graphql en el diagrama: max_rows: 1000 y inflect_names: true. pg_graphql tiene un límite predeterminado de 10 000 filas por colección; sin first:, una tabla grande puede saturar la memoria. inflect_names proporciona nombres de tipos legibles en lugar del caso de serpiente sin formato de las tablas SQL.

Ser documentado en lugar de oculto, en el espíritu de este blog.

• No hay suscripciones nativas a GraphQL. pg_graphql cubre consultas y mutaciones, no subscriptions en tiempo real; esta es una limitación de la extensión en sí, no una omisión de Aurabase. Aurabase en tiempo real existe, pero a través de un canal separado (postgres_changes), no un puente de suscripciones GraphQL.
• No hay acciones declarativas a la Hasura. El modelo de “webhook empresarial conectado a una mutación GraphQL” no tiene un equivalente directo: en Aurabase, esta lógica pasa por una función de Postgres o una función Edge, no por una configuración GraphQL dedicada.
• Reservado para el motor Postgres. Un proyecto MongoDB no puede habilitar esto; no se pretende ninguna solución alternativa.

Las tres opciones son legítimas: la elección correcta depende de lo que ya tienes y de lo que buscas evitar.

• pg_graphql en Aurabase: si su base de datos y políticas de RLS ya se encuentran en Aurabase y desea una segunda forma de consultarlas sin servicios adicionales que monitorear.
• Hasura: si federa múltiples fuentes de datos (no solo Postgres) detrás de un único esquema GraphQL, o si PromptQL y su enfoque de agente de IA se ajustan a su hoja de ruta.
• PostGraphile v5: si desea un control preciso sobre el esquema generado a través de su sistema de complementos y ya ejecuta un servidor Node.js en el que integrarlo.

Para conocer la sintaxis de consulta completa (filtros por tipo de columna, clasificación orderBy, paginación por cursor, mutaciones insertInto<Table>Collection), consulte la documentación oficial pg_graphql. La documentación de Aurabase GraphQL, a continuación, también detalla el ciclo completo.