FraiseQL vs Hasura

Both FraiseQL and Hasura provide GraphQL APIs over databases. Here’s how they differ.

The Fundamental Difference

Hasura is a runtime GraphQL engine that interprets queries and generates SQL on-the-fly.

FraiseQL is a compiled Rust binary that pre-generates optimized SQL views at build time — no runtime SQL generation, no resolver code.

Side-by-Side Comparison

Aspect	FraiseQL	Hasura
Architecture	Compiled Rust binary	Interpreted runtime engine
Query execution	Pre-built SQL views	Runtime SQL generation
N+1 handling	Eliminated by design	Runtime batching
Configuration	TOML	Console + YAML
Schema source	Code (Python, TS, Go…)	Database introspection
Database support	PostgreSQL, MySQL, SQLite, SQL Server	PostgreSQL (primary), others via connectors
Deployment	Single binary	Docker container + metadata
Performance	Predictable, sub-ms	Variable, depends on query
Custom logic	Observers (reactive events)	Actions (HTTP), Remote Schemas
Pricing	Open source (Apache 2.0)	Open source core, paid cloud
REST transport	✅ CQRS-derived + annotation override, OpenAPI 3.0.3, JSON envelope, filtering, ETags	⚠️ RESTified Endpoints (wraps a saved GraphQL query; no OpenAPI spec, no HTTP status-code mapping, no request-body parsing)
gRPC transport	✅ Transport-aware DB views, auto-generated .proto	❌ Requires external gateway
OpenAPI generation	✅ Auto-generated from compiled schema	❌

Pricing information accurate as of February 2026. Verify current pricing at hasura.io/pricing.

FraiseQL serves REST and gRPC alongside GraphQL from a single binary. Hasura’s RESTified Endpoints let you expose a saved GraphQL query as a REST URL, but they are not a first-class REST transport: there is no HTTP status-code mapping, no OpenAPI spec, and no request-body parsing. For gRPC clients, Hasura requires an external gateway.

Concept Mapping

If you know Hasura, here is how its concepts map to FraiseQL equivalents:

Hasura	FraiseQL Equivalent
Track table	Create SQL view (v_*)
Permissions (YAML)	PostgreSQL Row-Level Security
Event triggers	Observers
Actions	SQL functions + mutations
Remote schemas	Federation
Computed fields	SQL view expressions

Performance

FraiseQL Approach

-- Composed views: tb_ tables, v_ views, child .data embedded in parent
CREATE VIEW v_user AS
SELECT id, jsonb_build_object('id', id, 'name', name, 'email', email) AS data
FROM tb_user;

CREATE VIEW v_post AS
SELECT p.id,
    jsonb_build_object('id', p.id, 'title', p.title, 'author', vu.data) AS data
FROM tb_post p
JOIN v_user vu ON vu.id = p.fk_user;

Query execution: Single indexed view lookup

Hasura Approach

-- Generated at runtime per query
SELECT u.* FROM users u WHERE u.id = $1;
SELECT p.* FROM posts p WHERE p.author_id IN ($1, $2, ...);
-- Results assembled in memory

Query execution: Multiple queries + assembly

Configuration

FraiseQL: Single TOML File

fraiseql.toml

[project]
name = "my-api"

[database]
url = "${DATABASE_URL}"

[server]
port = 8080

# JWT authentication via env var (no [auth] section in fraiseql.toml)
JWT_SECRET=your-256-bit-secret

Hasura: Console + YAML + Database Metadata

config.yaml

version: 3
metadata_directory: metadata
actions:
  handler_webhook_baseurl: http://localhost:3000

Plus separate files for:

• tables.yaml
• relationships.yaml
• permissions.yaml
• remote_schemas.yaml
• etc.

Schema Definition

FraiseQL: Code-First

Python

@fraiseql.type
class User:
    """User with posts."""
    id: str
    name: str
    email: str
    posts: list['Post']

TypeScript

import { Type } from 'fraiseql';

@Type()
class User {
    id!: string;
    name!: string;
    email!: string;
    posts!: Post[];
}

Go

import "github.com/fraiseql/fraiseql-go"

type User struct {
    ID    fraiseql.ID `fraiseql:"id"`
    Name  string      `fraiseql:"name"`
    Email string      `fraiseql:"email"`
    Posts []Post      `fraiseql:"posts"`
}

• Full IDE support
• Type checking
• Refactoring tools
• Version control friendly

Hasura: Database-First

1. Create tables in database
2. Hasura introspects schema
3. Configure relationships in console
4. Track tables/views

• Quick to start
• Limited to database capabilities
• Configuration in metadata

Custom Logic

FraiseQL: Observers

FraiseQL uses observers for reactive business logic — you define conditions and actions that trigger on database changes:

Caution

The TOML examples below use [[observers.rules]], [[observers.rules.actions]], and [observers.rules.retry] as illustrative syntax for complex multi-action rules. The verified production syntax from the TOML configuration reference uses [[observers.handlers]] for individual handler entries. If you are configuring observers in production, use [[observers.handlers]] as documented in the reference — the rules/actions nesting shown here may not parse correctly.

TOML

fraiseql.toml

[observers]
backend = "nats"
nats_url = "nats://localhost:4222"

[[observers.rules]]
entity = "Order"
event = "INSERT"
condition = "total > 1000"

[[observers.rules.actions]]
type = "webhook"
url = "https://api.example.com/high-value-orders"

[[observers.rules.actions]]
type = "slack"
channel = "#sales"
message = "High-value order {id}: ${total}"

[[observers.rules.actions]]
type = "email"
to = "sales@example.com"
subject = "High-value order {id}"
body = "Order {id} for ${total} was created"

[observers.rules.retry]
max_attempts = 5
backoff_strategy = "exponential"

TypeScript

import { observer, webhook, slack, email } from 'fraiseql';

observer({
    entity: 'Order',
    event: 'INSERT',
    condition: 'total > 1000',
    actions: [
        webhook('https://api.example.com/high-value-orders'),
        slack('#sales', 'High-value order {id}: ${total}'),
        email({
            to: 'sales@example.com',
            subject: 'High-value order {id}',
            body: 'Order {id} for ${total} was created',
        }),
    ],
    retry: { maxAttempts: 5, backoffStrategy: 'exponential' },
});

Built-in actions for webhooks, Slack, and email. No external services required.

Hasura

actions.yaml

- name: processOrder
  definition:
    kind: synchronous
    handler: http://business-logic-service:3000/process-order

Plus a separate HTTP service to handle the logic. Hasura also has event triggers, but they require external webhook handlers.

Event Triggers vs Observers

Hasura: Event Trigger YAML

metadata/event_triggers/on_order_created.yaml

- name: on_order_created
  definition:
    enable_manual: false
    insert:
      columns: "*"
  retry_conf:
    num_retries: 3
    interval_sec: 30
    timeout_sec: 60
  webhook: https://my-service.example.com/on-order-created
  headers:
    - name: X-Webhook-Secret
      value_from_env: WEBHOOK_SECRET

Hasura calls your external HTTP webhook. You own and deploy a separate service to handle the event.

FraiseQL: Observer Rules

Caution

The TOML tab below uses [[observers.rules]] as illustrative syntax. The verified production handler syntax is [[observers.handlers]] — see the TOML configuration reference.

TOML

fraiseql.toml

[observers]
backend = "nats"
nats_url = "nats://localhost:4222"

[[observers.rules]]
entity = "Order"
event = "INSERT"

[[observers.rules.actions]]
type = "webhook"
url = "https://my-service.example.com/on-order-created"

[observers.rules.actions.headers]
X-Webhook-Secret = "{env.WEBHOOK_SECRET}"

[[observers.rules.actions]]
type = "slack"
channel = "#orders"
message = "New order {id} received"

[observers.rules.retry]
max_attempts = 3
interval_sec = 30
timeout_sec = 60

TypeScript

import { observer, webhook, slack } from 'fraiseql';

observer({
    entity: 'Order',
    event: 'INSERT',
    actions: [
        webhook('https://my-service.example.com/on-order-created', {
            headers: { 'X-Webhook-Secret': '{env.WEBHOOK_SECRET}' },
        }),
        slack('#orders', 'New order {id} received'),
    ],
    retry: { maxAttempts: 3, intervalSec: 30, timeoutSec: 60 },
});

Go

import "github.com/fraiseql/fraiseql-go"

func init() {
    fraiseql.Observer(fraiseql.ObserverConfig{
        Entity: "Order",
        Event:  "INSERT",
        Actions: []fraiseql.Action{
            fraiseql.Webhook("https://my-service.example.com/on-order-created",
                fraiseql.WithHeader("X-Webhook-Secret", "{env.WEBHOOK_SECRET}")),
            fraiseql.Slack("#orders", "New order {id} received"),
        },
        Retry: fraiseql.RetryConfig{MaxAttempts: 3, IntervalSec: 30, TimeoutSec: 60},
    })
}

The key difference: Hasura event triggers require you to host an external HTTP service. FraiseQL observers are configured in fraiseql.toml — actions like webhook, slack, and email are built-in to the FraiseQL runtime, with no separate service required.

Input Validation

FraiseQL: Compile-Time Validation

FraiseQL enforces access control during schema compilation, before any query executes:

• Scope-based field access control — requires JWT scopes to read or write protected fields
• No runtime overhead — access rules are baked into the compiled schema
• Impossible to deploy invalid schemas — configuration conflicts caught at build time
• Zero database errors — unauthorized writes never reach the database

Access control rules are declared directly on fields using fraiseql.field():

from typing import Annotated
import fraiseql

@fraiseql.input
class CreateUserInput:
    email: str
    age: int
    phone: str

    # Protected field — requires admin scope to set
    role: Annotated[str, fraiseql.field(
        requires_scope="admin:write",
        on_deny="reject",
        description="User role — admin only",
    )]

Hasura: Runtime Validation

Hasura relies primarily on GraphQL’s built-in type system for validation:

• Type checking — scalar types, required fields (from GraphQL spec)
• Basic validation — Only what the type system provides
• Runtime only — Validation happens during query execution
• Custom validation via Actions — HTTP webhooks for complex logic

For anything beyond GraphQL type checking, Hasura users must implement custom Actions (external HTTP services).

Comparison

Aspect	FraiseQL	Hasura
Field access control	Scope-based (compile-time)	Permissions YAML
Compile-time enforcement	✅ Yes	❌ No
Cross-field validation	✅ Yes (PostgreSQL CHECK constraints)	❌ Custom Actions required
Database protection	Unauthorized data impossible	Possible without Actions
Configuration	Declarative TOML	GraphQL directives + Actions

When to Use Hasura

Hasura is a better choice when:

• You need rapid prototyping — Point at a database, get instant API
• Your team prefers GUI configuration — Console-based setup
• You have an existing database — Introspection works great
• You need event triggers — Hasura’s event system is mature
• You want managed hosting — Hasura Cloud is polished

When to Use FraiseQL

FraiseQL is a better choice when:

• You want predictable performance — Compiled queries, no surprises
• You prefer code over configuration — Schema in your language
• You need multi-database support — PostgreSQL, MySQL, SQLite, SQL Server
• You want simple deployment — Single Rust binary, no orchestration
• You value readability — TOML over YAML, one file over many

Quick Test: Hasura vs FraiseQL

1. Start Hasura locally:

   docker run -d --name hasura \
     -p 8080:8080 \
     -e HASURA_GRAPHQL_DATABASE_URL=postgresql://user:pass@host/db \
     hasura/graphql-engine:latest

   Open the console at http://localhost:8080/console

   Manual steps required:

   • Click “Data” → “Manage”
   • Track each table manually
   • Configure relationships in UI
   • Set permissions via YAML
   • Export metadata for version control

2. Create the same API with FraiseQL:

   # fraiseql.toml - single file
   [database]
   url = "${DATABASE_URL}"

   # schema.py - code-first
   import fraiseql
   
   @fraiseql.type
   class User:
       id: str
       name: str
       email: str
       posts: list['Post']
   
   @fraiseql.type
   class Post:
       id: str
       title: str
       author: User

   fraiseql run

   No manual configuration — schema derived from code automatically.

3. Compare query performance:

   Hasura generates SQL at runtime:

   -- Generated per request
   SELECT * FROM users WHERE ...;
   SELECT * FROM posts WHERE user_id IN (...);

   FraiseQL uses pre-built views:

   -- Single view query
   SELECT data FROM v_user WHERE id = $1;

4. Test GraphQL introspection:

   # Both expose same introspection
   curl -X POST http://localhost:8080/v1/graphql \
     -H "Content-Type: application/json" \
     -d '{"query": "{ __schema { types { name } } }"}'
   
   curl -X POST http://localhost:8080/graphql \
     -H "Content-Type: application/json" \
     -d '{"query": "{ __schema { types { name } } }"}'

Migration from Hasura

Step 1: Export Your Schema

# Get your Hasura table definitions
hasura metadata export

Step 2: Convert to FraiseQL Types

Hasura table:

tables.yaml

- table:
    name: users
    schema: public
  object_relationships:
    - name: posts
      using:
        foreign_key_constraint_on:
          column: author_id
          table:
            name: posts

FraiseQL equivalent:

Python

@fraiseql.type
class User:
    id: str
    name: str
    email: str
    posts: list['Post']

@fraiseql.type
class Post:
    id: str
    title: str
    author: User

TypeScript

import { Type } from 'fraiseql';

@Type()
class User {
    id!: string;
    name!: string;
    email!: string;
    posts!: Post[];
}

@Type()
class Post {
    id!: string;
    title!: string;
    author!: User;
}

Go

import "github.com/fraiseql/fraiseql-go"

type User struct {
    ID    fraiseql.ID `fraiseql:"id"`
    Name  string      `fraiseql:"name"`
    Email string      `fraiseql:"email"`
    Posts []Post      `fraiseql:"posts"`
}

type Post struct {
    ID     fraiseql.ID `fraiseql:"id"`
    Title  string      `fraiseql:"title"`
    Author User        `fraiseql:"author"`
}

Step 3: Migrate Actions to Observers

Hasura Action:

- name: processPayment
  definition:
    kind: synchronous
    handler: http://payments:3000/process

FraiseQL observer (TOML-based configuration):

Caution

The snippet below uses [[observers.rules]] as illustrative syntax. The verified production handler syntax is [[observers.handlers]] — see the TOML configuration reference.

fraiseql.toml

[[observers.rules]]
entity = "Order"
event = "UPDATE"
condition = "status = 'pending_payment'"

[[observers.rules.actions]]
type = "webhook"
url = "https://payments.internal/process"

[observers.rules.actions.body]
order_id = "{id}"
amount = "{total}"

Quick Migration

Already on Hasura and want to try FraiseQL? Here are the three core steps:

1. Install the FraiseQL CLI

   # Download the FraiseQL binary
   curl -fsSL https://install.fraiseql.dev | sh
   
   # Verify installation
   fraiseql --version

2. Convert your Hasura YAML to a FraiseQL schema

   Export your Hasura metadata, then rewrite each table definition as a FraiseQL type and write the corresponding SQL views (v_*) to enforce permissions:

   # Export existing Hasura configuration
   hasura metadata export
   
   # Inspect generated metadata
   ls metadata/databases/default/tables/

   For each Hasura table, create a FraiseQL type and a SQL view. See the examples above for the conversion pattern, or refer to the full migration guide.

3. Run FraiseQL

   # Start the FraiseQL server pointing at your existing database
   fraiseql run --config fraiseql.toml

   FraiseQL will read your schema types, connect to your database, and serve the GraphQL API on the configured port. You can keep Hasura running in parallel during the transition.

For a complete walkthrough including subscription migration and permission replication, see the Migrating from Hasura guide.

Migrating from Hasura? See the step-by-step migration guide.

Summary

Choose	When
Hasura	Rapid prototyping, existing databases, GUI preference
FraiseQL	Predictable performance, code-first, multi-database

Both are excellent tools. Choose based on your team’s preferences and requirements.

---

Next Steps

Build Your First API

Get a working GraphQL API in minutes. Quick Start Guide

Performance Benchmarks

See how FraiseQL performs with real numbers. View Benchmarks

Migrate from Hasura

Step-by-step guide to moving your existing Hasura setup. Migration Guide

How FraiseQL Works

Understand the compiled, database-first architecture. Core Concepts