PostgREST frente a Hasura frente a una API personalizada

La pregunta "PostgREST o Hasura o API personalizada" esconde una pregunta más útil: ¿quién escribe su lógica de negocios, con qué herramienta y quién usa este código en producción? Las tres arquitecturas responden de manera diferente, y esta diferencia estructura todo lo demás: seguridad, velocidad de implementación, deuda técnica a largo plazo.

Ninguna de las tres columnas es estrictamente mejor: cada una traslada el trabajo a otra parte. PostgREST lo traslada a SQL, Hasura a la configuración y webhooks, una API personalizada al código de aplicación clásico.

PostgREST transforma su esquema de Postgres en una API REST (filtros, incrustación de relaciones, RPC, RLS impulsado por JWT) sin backend para escribir. Este alcance lo detallamos en profundidad en nuestro artículo sobre su compatibilidad real con y sus alternativas; lo que importa para esta comparación es dónde termina PostgREST.

PostgREST no tiene noción de lógica empresarial arbitraria. Cada regla debe expresarse en SQL: una función RPC, un disparador, una restricción, una política RLS. Esta es una restricción aceptada, no un descuido: el diagrama sigue siendo la única fuente de verdad, que elimina cualquier deriva entre una capa de aplicación y la base a la que sirve.

En concreto, es imposible llamar a un servicio de pago de terceros, enviar un correo electrónico de confirmación o calcular una puntuación en JavaScript a partir de una solicitud PostgREST directa. Esta lógica debe vivir en SQL (función pl/pgsql) o activarse externamente: un activador que publica un evento NOTIFY, escuchado por un servicio externo que ya no es PostgREST.

Nuestro artículo sobre capas GraphQL en Postgres detalla dónde se ejecuta el motor Hasura y en qué se diferencian sus permisos de Postgres RLS. Aquí, el ángulo es el de la lógica empresarial: cómo conectar código personalizado a una base de datos administrada por Hasura, y dónde.

Una acción Hasura expone una mutación o consulta GraphQL personalizada, respaldada por un webhook HTTP que usted escribe en el idioma de su elección. Hasura valida las entradas de acuerdo con el esquema declarado, llama a tu webhook y luego devuelve su respuesta al cliente. Es la puerta de entrada a cualquier lógica que vaya más allá de CRUD: llamada a un proveedor de pagos, cálculo complejo, orquestación de varios pasos.

Los Event Triggers siguen la dirección opuesta: una inserción, una actualización o una eliminación en una tabla activa un webhook, de forma asincrónica y con reinicio automático en caso de falla. Este es el mecanismo que utilizan la mayoría de las integraciones de Hasura para sincronizar un servicio de terceros (facturación, correo electrónico transaccional, motor de búsqueda) sin acoplar este código a la solicitud inicial del cliente.

Hasura también puede exponer una consulta GraphQL ya escrita como una ruta REST típica, con una ruta con nombre y parámetros: sus puntos finales RESTified, en la terminología de su propia documentación. Útil si su equipo de frontend prefiere consumir REST, sin renunciar al motor de permisos GraphQL subyacente.

Recordatorio de contexto, desarrollado en nuestro artículo dedicado: Hasura ha reorientado su comunicación en PromptQL, una capa diseñada para agentes de IA, desde junio de 2025, sin eliminar su motor GraphQL, que todavía se presenta como "probado en batalla" en su sitio web oficial.

Una API escrita a mano, por definición, no tiene límites: cualquier lógica de negocio, en cualquier idioma, con cualquier dependencia. También es la única de las tres opciones en la que no se genera nada para usted: cada ruta, cada validación, cada conexión a la base de datos es un código que le pertenece y debe mantener.

// El filtro, la clasificación y la incrustación de relaciones están escritos a mano,
// solo para esta ruta: repita para cada recurso API
router.get('/orders', async (req, res) => {
  const { status } = req.query
  const result = await db.query(
    `SELECT o.id, o.total, c.email AS customer_email
     FROM orders o JOIN customers c ON c.id = o.customer_id
     WHERE o.status = $1 ORDER BY o.created_at DESC`,
    [status]
  );
  res.json(result.rows)
});

Lo que ofrece este modelo, a cambio del trabajo manual: control total sobre errores y códigos HTTP devueltos, capacidad de prueba clásica (controladores, configuración no declarativa) y ningún DSL nuevo que aprender para un equipo que ya domina su lenguaje.

Lo que cuesta, a cambio: CRUD, paginación y filtros para escribir y mantener a mano para cada recurso; autenticación y autorización para implementar y auditar usted mismo, sin RLS heredado automáticamente; el riesgo de consultas N+1 si cada relación anidada desencadena su propia consulta de Postgres sin disciplina; y la documentación API se mantendrá manualmente o mediante un generador de terceros para su integración.

En cuanto al rendimiento bruto, la pregunta "¿Es Node.js más lento que Rust" es un tema en sí mismo: nuestro artículo sobre Latencia de Rust vs Node.js lo cubre en detalle, con la metodología declarada en sentido ascendente en nuestra página de metodología de referencia . Una API personalizada tiene el mismo perfil de rendimiento que cualquier servicio HTTP que ya utilice, ni mejor ni peor por construcción. Para saber con precisión dónde se satura PostgREST y en qué punto se vuelve necesaria una capa personalizada, consulte nuestro artículo sobre los límites reales de PostgREST en producción.

Más allá de la arquitectura, cuatro criterios surgen con mayor frecuencia al elegir: velocidad de implementación, flexibilidad comercial real, deuda técnica a largo plazo y el caso de uso típico donde cada opción es más cómoda.

En un proyecto de motor Aurabase Postgres, la capa CRUD ya está cubierta por una instancia PostgREST real, no por una reimplementación aproximada. La pregunta que queda abierta para esta comparación: ¿dónde escribir lo que va más allá del CRUD?

Existen dos caminos y no son mutuamente excluyentes. La primera: una función SQL expuesta en RPC, para cualquier lógica que sea razonable expresar en SQL: cálculo de un total, validación cruzada entre varias tablas, actualizaciones en cascada en una sola transacción.

curl -X POST "https://<gateway>/v1/db/<project_id>/rpc/apply_discount" \
  -H "apikey: <votre-cle-api>" \
  -H "Content-Type: application/json" \
  -d '{"order_id": 42, "code": "WELCOME10"}'

La segunda forma: Edge Functions, para todo lo que va más allá del dominio SQL: llamar a una API de pago, enviar un correo electrónico, calcular una incrustación. Dos caminos conducen allí en Aurabase: el editor Studio, que ejecuta código Deno (TypeScript) exactamente como en Supabase, y la CLI aura functions deploy, que apunta a una ruta separada para funciones escritas en Rust y compiladas en WASM, detalladas en nuestra arquitectura unificada de Rust . Ninguna de las rutas requiere alojar un servidor Node separado, a diferencia de la opción pura "API personalizada" de este artículo, donde ese servidor es enteramente su responsabilidad.

Esta distribución no es un compromiso inestable entre los tres modelos comparados aquí: es literalmente PostgREST para CRUD, un ladrillo cercano a Hasura Actions para lógica de eventos a través de RPC y disparadores, y Edge Functions que evitan la operación de un servidor de aplicaciones completo, sin forzar nunca una elección binaria entre "todo PostgREST" y "todo personalizado".

Cuatro situaciones surgen con mayor frecuencia. La elección correcta depende principalmente de lo que requiera su lógica empresarial, no de la popularidad de una herramienta.

• Su esquema es estable y su lógica de negocios está en SQL. PostgREST autohospedado, o integrado de forma nativa (Aurabase, Supabase), es suficiente: nada más que alojar, y el esquema sigue siendo la única fuente de verdad.
• Quiere reunir varias fuentes de datos o su hoja de ruta está orientada a que los agentes de IA consuman sus datos. Hasura, con su capa PromptQL, se adapta mejor a este terreno.
• Su producto tiene una rica lógica empresarial, numerosas integraciones con terceros y un equipo ya equipado con un lenguaje de aplicación. Una API personalizada sigue siendo la opción más directa, a costa de escribirla y mantenerla a lo largo del tiempo.
• Quiere CRUD autogenerado sin renunciar a espacio real para la lógica empresarial (RPC, funciones perimetrales), sin acumular un servicio de aplicación más para explotar. Este es el ángulo documentado en esta comparación aplicada a Aurabase, sección anterior.