Skip to content

Introduction

FraiseQL is a database-first GraphQL framework. You write SQL views, FraiseQL maps them to GraphQL types, and every query resolves to a single SQL statement. No resolvers. No N+1. No magic.

Traditional GraphQL frameworks require you to:

  1. Write resolvers for every field and relationship
  2. Handle N+1 queries manually with DataLoaders
  3. Tune performance at runtime with caching layers
  4. Debug surprises that only appear in production

This leads to boilerplate code, runtime unpredictability, and hours spent debugging performance issues.

FraiseQL compiles the relationship between GraphQL types and SQL views at build time. At runtime, a GraphQL query becomes a single SQL statement — not a cascade of resolver calls.

Traditional GraphQLFraiseQL
Write resolver functionsWrite SQL views
Handle N+1 with DataLoadersN+1 eliminated by design
Tune performance at runtimePerformance compiled in
YAML / JSON configurationTOML you can read
Debug resolver chainsDebug SQL — you own it
  1. Write tables and views in SQL for your database.

    CREATE VIEW v_post AS
    SELECT
    p.id,
    jsonb_build_object(
    'id', p.id,
    'title', p.title,
    'author', row_to_json(u)
    ) AS data
    FROM tb_post p
    JOIN tb_user u ON u.id = p.author_id;
  2. Define types in your preferred language.

    @fraiseql.type
    class Post:
    id: UUID
    title: str
    author: User
  3. Configure with a single TOML file.

    fraiseql.toml
    [project]
    name = "my-api"
    [database]
    type = "postgresql"
    url = "${DATABASE_URL}"
    [server]
    port = 8080
  4. Build and serve.

    Terminal window
    fraiseql compile
    fraiseql run

    Your GraphQL API is live. Every query resolves to the SQL view you wrote.

Any Database

PostgreSQL, MySQL, SQLite, and SQL Server. Full multi-database support with database-specific optimizations.

Any Language

Define schemas in Python, TypeScript, Go, Java, Rust, and 12+ more. All compile to the same output.

No N+1 by Design

SQL views pre-join relationships. FraiseQL never issues N+1 queries — it’s architecturally impossible.

Compile-Time Validation

13 built-in validators catch errors at build time. Invalid schemas cannot be deployed.

You Own the SQL

You write the views. You see the query that runs. Full debuggability and control.

Rust Performance

Sub-millisecond query routing. The binary is a single compiled executable with no runtime dependencies.

FraiseQL supports four databases:

DatabaseStatusNotes
PostgreSQL✅ RecommendedBest JSONB support, row-level security, full-text search
MySQL✅ SupportedJSON column support, MySQL 8.0+
SQLite✅ SupportedIdeal for development and embedded use
SQL Server✅ SupportedFOR JSON PATH, SQL Server 2019+
Oracle❌ Not supportedNo plans to add support

FraiseQL is ideal when you need:

  • High performance — query latency driven by SQL, not resolver chains
  • Predictability — deterministic, compiled behavior; no runtime surprises
  • SQL ownership — your team writes and reviews the queries that run
  • Rapid development — no resolver boilerplate to write or maintain

FraiseQL isn’t the right tool for every use case. Consider alternatives if you need:

  • Complex business logic in resolvers — FraiseQL is database-first; intricate middleware logic belongs in a service layer
  • GraphQL federation across microservices — FraiseQL federates databases, not arbitrary services
  • Oracle — explicitly not supported