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

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

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

[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

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

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

import { type } from 'fraiseql';

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

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

Create tables in database
Hasura introspects schema
Configure relationships in console
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:

Python
TypeScript

from fraiseql import observer, webhook, slack, email
from fraiseql.observers import RetryConfig

@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=RetryConfig(max_attempts=5, backoff_strategy="exponential"),
)
def on_high_value_order():
    """Triggered when a high-value order is created."""
    pass

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

- 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

- 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` Decorator

from fraiseql import observer, webhook, slack, email
from fraiseql.observers import RetryConfig

@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=RetryConfig(max_attempts=3, interval_sec=30, timeout_sec=60),
)
def on_order_created():
    """Triggered when a new order is inserted."""
    pass

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 },
});

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 declared inline in your schema code — actions like webhook, slack, and email are built-in, with no separate service required.

Input Validation

FraiseQL: Compile-Time Validation

FraiseQL enforces validation during schema compilation, before any query executes:

13 built-in validators across 4 categories
- Standard: required, pattern, length, range, enum, checksum
- Cross-field: comparison operators, conditionals
- Mutual exclusivity: OneOf, AnyOf, ConditionalRequired, RequiredIfAbsent
No runtime overhead — validation rules are baked into the schema
Impossible to deploy invalid schemas — validation rule conflicts caught at build time
Zero database errors — invalid data never reaches the database

All validation is declarative — rules are defined via decorators in your schema code:

@fraiseql.type
class CreateUserInput:
    email: Annotated[str, fraiseql.field(pattern=r"^[^@]+@[^@]+\.[^@]+$")]
    age: Annotated[int, fraiseql.field(range={"min": 0, "max": 150})]
    phone: Annotated[str, fraiseql.field(length=10)]

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
Built-in validators	13 rules	~3 (via GraphQL types)
Compile-time enforcement	✅ Yes	❌ No
Mutual exclusivity	OneOf, AnyOf, ConditionalRequired, RequiredIfAbsent	@oneOf only
Cross-field validation	✅ Yes	❌ Custom Actions required
Database protection	Invalid 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

Start Hasura locally:
Terminal window
```
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

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.

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;

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:

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

FraiseQL equivalent:

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

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

import { type } from 'fraiseql';

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

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

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:

@observer(
    entity="Order",
    event="UPDATE",
    condition="status = 'pending_payment'",
    actions=[
        webhook("https://payments.internal/process",
                body={"order_id": "{id}", "amount": "{total}"}),
    ],
)
def on_pending_payment():
    """Process payment when order status changes."""
    pass

Quick Migration

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

Install the FraiseQL CLI

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

# Verify installation
fraiseql --version

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:
Terminal window
```
# 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.
Run FraiseQL
Terminal window
```
# 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