🍓 Database-First GraphQL for PostgreSQL

Build GraphQL APIs
Directly on PostgreSQL

Production-ready framework with enterprise patterns built-in. Sub-5ms responses with APQ and TurboRouter.

GraphQL Query

{
  users {
    id
    name
    posts {
      title
      comments {
        text
      }
    }
  }
}

↓

One PostgreSQL Query

SELECT jsonb_agg(
  jsonb_build_object(
    'id', u.id,
    'name', u.name,
    'posts', u.posts
  )
) FROM users u

Why FraiseQL?

⚡ APQ with Multi-Tenant Isolation

0.5-2ms cached responses. Up to 99.9% cache hit rates. Tenant-aware caching in PostgreSQL or memory. No Redis needed.

Learn more →

🚀 Hybrid Table Optimization

Automatically uses indexed columns for 10-100x faster queries. Seamlessly combines SQL columns with JSONB flexibility.

Learn more →

🏎️ TurboRouter

Zero-copy JSON passthrough from PostgreSQL to client. No Python object instantiation overhead. 4-10x faster.

Learn more →

🏗️ Database-First CQRS

Views for queries, PostgreSQL functions for mutations. ACID guarantees with structured error handling.

Learn more →

🎯 Specialized PostgreSQL Types

Native IPv4/IPv6, LTree hierarchies, DateRange. Type-aware operators no other GraphQL framework has.

Learn more →

🔧 FastAPI Native

Built for FastAPI. Async-first, type-safe, LLM-optimized development with dependency injection.

Learn more →

Quick Start

1. Install

pip install fraiseql

2. Define Schema

import fraiseql

@fraiseql.type
class User:
    id: int
    name: str

@fraiseql.query
async def users(info) -> list[User]:
    return await info.context.repo.fetch()

3. Run

from fraiseql.fastapi import create_app

app = create_app(
    database_url="postgresql://localhost/db"
)

Performance That Matters

Scenario	Traditional ORM	FraiseQL	Improvement
Nested data (3 levels)	~50 queries	1 query	50x fewer
Response time (1000 users)	~800ms	~45ms	17x faster
Memory usage	~120MB	~25MB	5x less

* Performance metrics based on 3-level nested query (users → posts → comments) with PostgreSQL 14, comparing Django ORM to FraiseQL. Results vary based on data size and query complexity.

When NOT to Use FraiseQL

We believe in honest engineering. FraiseQL isn't for everyone:

❌ Need multiple database support (PostgreSQL 13+ only, by design)
❌ Need GraphQL subscriptions (not yet implemented)
❌ Existing large codebase with different ORM patterns
❌ Complex business logic in the GraphQL layer (use PostgreSQL Functions instead)
❌ Pre-1.0 concerns (v0.9.5 is stable, but APIs may evolve before 1.0)

If these are deal-breakers, check out Hasura or PostGraphile.

Build GraphQL APIsDirectly on PostgreSQL

Why FraiseQL?

Quick Start

Performance That Matters

When NOT to Use FraiseQL

Build GraphQL APIs
Directly on PostgreSQL