FraiseQL vs Prisma

Prisma is a popular ORM. FraiseQL is a GraphQL framework backed by a Rust binary. Here’s why you might choose one over the other.

The Fundamental Difference

Prisma is an ORM that generates a type-safe database client. You still need to build your API layer (Express, Fastify, Apollo, etc.).

Prisma generates a client library; FraiseQL serves a multi-transport API server. REST, GraphQL, and gRPC clients connect directly to FraiseQL — no client library needed on the server side.

FraiseQL generates the entire GraphQL API, including the database access layer — backed by hand-written PostgreSQL views (v_*) for reads and PostgreSQL functions (fn_*) for writes.

With Prisma:
  Your Code -> Prisma Client -> Database
  (You build the API layer)

With FraiseQL:
  Client -> GraphQL -> FraiseQL Rust Binary -> PostgreSQL Views/Functions
  (API layer is built-in)

Side-by-Side Comparison

Aspect	FraiseQL	Prisma
What it is	GraphQL framework (Rust binary)	ORM / Database client
Output	Complete GraphQL API	Database client library
API layer	Included	Build yourself
Schema source	Python, TypeScript, Go decorators	Prisma Schema Language
Reads	Pre-compiled PostgreSQL views (v_*)	Generated SQL via ORM
Writes	PostgreSQL functions (fn_*)	Generated SQL via ORM
N+1 handling	Eliminated by design (SQL JOINs in views)	include option (manual)
Query language	GraphQL	Prisma Client API
Configuration	TOML	.prisma files
Database support	PostgreSQL-first	PostgreSQL, MySQL, SQLite, SQL Server, MongoDB
Runtime	Rust binary	Node.js

What You Build

With Prisma

// 1. Define Prisma schema
// schema.prisma
model User {
  id    String @id @default(uuid())
  name  String
  email String @unique
  posts Post[]
}

model Post {
  id       String @id @default(uuid())
  title    String
  author   User   @relation(fields: [authorId], references: [id])
  authorId String
}

// 2. Generate client
// $ prisma generate

// 3. Build your API layer (Express, Fastify, Apollo, etc.)
app.get('/users', async (req, res) => {
  const users = await prisma.user.findMany({
    include: { posts: true }
  });
  res.json(users);
});

app.get('/users/:id', async (req, res) => {
  const user = await prisma.user.findUnique({
    where: { id: req.params.id },
    include: { posts: true }
  });
  res.json(user);
});

app.post('/users', async (req, res) => {
  const user = await prisma.user.create({
    data: req.body
  });
  res.json(user);
});

// ... 50+ more endpoints

With FraiseQL

# 1. Define schema with decorators
@fraiseql.type
class User:
    id: str
    name: str
    email: str
    posts: list['Post']

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

# 2. Declare queries (backed by PostgreSQL views)
@fraiseql.query
def users(limit: int = 50) -> list[User]:
    return fraiseql.config(sql_source="v_user")

# 3. Build and serve
# $ fraiseql run

# Done. Full GraphQL API is ready.

-- The backing SQL view (you write this)
CREATE VIEW v_user AS
SELECT u.id,
    jsonb_build_object(
        'id',    u.id::text,
        'name',  u.name,
        'email', u.email,
        'posts', COALESCE(
            jsonb_agg(jsonb_build_object('id', p.id::text, 'title', p.title))
            FILTER (WHERE p.pk_post IS NOT NULL),
            '[]'::jsonb
        )
    ) AS data
FROM tb_user u
LEFT JOIN tb_post p ON p.fk_user = u.pk_user
GROUP BY u.pk_user, u.id;

Note

FraiseQL requires writing SQL views and PostgreSQL functions. This is more upfront work than Prisma’s ORM approach, but gives you complete control over query shape, performance, and security — and the Rust binary executes those pre-written queries without generating SQL at runtime.

N+1 Query Handling

Prisma: Manual include

// Without include: N+1 problem
const users = await prisma.user.findMany();
for (const user of users) {
  user.posts = await prisma.post.findMany({
    where: { authorId: user.id }
  }); // N queries!
}

// With include: You must remember to add it
const users = await prisma.user.findMany({
  include: { posts: true }
});

If you forget include, you get N+1. If you include too much, you fetch unnecessary data.

FraiseQL: Eliminated by Design

# This query:
query {
  users {
    name
    posts { title }
  }
}

Because the v_user view already JOINs tb_post, this resolves in a single SQL execution. You cannot accidentally create N+1 queries — the SQL is pre-compiled into the view.

Schema Language

Prisma (PSL)

schema.prisma

model User {
  id        String   @id @default(uuid())
  email     String   @unique
  name      String?
  posts     Post[]
  createdAt DateTime @default(now())

  @@index([email])
  @@map("users")
}

model Post {
  id        String   @id @default(uuid())
  title     String
  content   String?
  published Boolean  @default(false)
  author    User     @relation(fields: [authorId], references: [id])
  authorId  String

  @@map("posts")
}

• Custom DSL to learn
• Good tooling (VS Code extension)
• Limited to Prisma’s feature set

FraiseQL (Python decorators)

schema.py

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

@fraiseql.type
class Post:
    id: str
    title: str
    content: str | None
    published: bool = False
    author: User

• Use your existing language (Python, TypeScript, or Go)
• Full IDE support with standard tooling
• Any language features available (inheritance, generics, etc.)

Input Validation

Prisma: External Libraries

Prisma doesn’t include validation — you must use external libraries:

// Prisma + Zod for validation
import { z } from 'zod';

const createUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1),
  age: z.number().min(0).max(150)
});

app.post('/users', async (req, res) => {
  const validated = createUserSchema.parse(req.body); // Runtime validation
  const user = await prisma.user.create({
    data: validated
  });
  res.json(user);
});

• External dependencies — Zod, Joi, Yup, etc.
• Runtime validation — Happens during request handling
• Your responsibility — Must validate before database calls
• Database risk — Invalid data if validation is missed

FraiseQL: Built-In Access Control

FraiseQL enforces field-level access control at compile time via fraiseql.field():

from typing import Annotated
import fraiseql

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

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

• Scope-based field access control — No external libraries needed
• Compile-time enforcement — Invalid schemas are impossible at runtime
• Zero dependencies — Everything built-in to the FraiseQL schema compiler
• Database protection — Unauthorized writes never reach the database

Validation Comparison

Aspect	FraiseQL	Prisma
Field access control	Scope-based (compile-time)	None (requires external libs)
External dependencies	None	Zod, Joi, Yup, etc.
Compile-time enforcement	Yes	No
Runtime validation overhead	None	Per-request
Learning curve	Low	Medium (varies by library)
Database protection	Guaranteed	Depends on implementation

When to Use Prisma

Prisma is a better choice when:

• You’re building a REST API — Prisma doesn’t prescribe your API layer
• You need fine-grained control — Build exactly the endpoints you want
• You want GraphQL with custom resolvers — Prisma + Apollo/Yoga/etc.
• You need MongoDB support — FraiseQL is PostgreSQL-first
• Your API has complex business logic — More control over request handling
• You prefer auto-generated SQL — No SQL views to write upfront

When to Use FraiseQL

FraiseQL is a better choice when:

• You want a GraphQL API — It’s built-in, no extra layer to wire up
• You want less application code — Schema + SQL views, no API layer
• You need guaranteed N+1 prevention — By design, not by discipline
• You prefer compiled output — Rust binary with predictable performance
• You want simple configuration — TOML over multiple files
• You trust your SQL — Write the queries you know are optimal

Quick Test: Prisma vs FraiseQL

1. Create a Prisma project:

   npm init -y
   npm install @prisma/client prisma
   npx prisma init

   Edit schema.prisma:

   generator client {
     provider = "prisma-client-js"
   }
   
   datasource db {
     provider = "postgresql"
     url      = env("DATABASE_URL")
   }
   
   model User {
     id    String @id @default(uuid())
     email String @unique
     name  String
     posts Post[]
   }
   
   model Post {
     id       String @id @default(uuid())
     title    String
     author   User   @relation(fields: [authorId], references: [id])
     authorId String
   }

   npx prisma migrate dev --name init
   npx prisma generate

2. Build the API layer manually:

   // server.js - You must build this yourself
   const { PrismaClient } = require('@prisma/client');
   const express = require('express');
   
   const prisma = new PrismaClient();
   const app = express();
   
   app.get('/users', async (req, res) => {
     const users = await prisma.user.findMany({
       include: { posts: true }  // Remember this or get N+1!
     });
     res.json(users);
   });
   
   app.get('/users/:id', async (req, res) => {
     const user = await prisma.user.findUnique({
       where: { id: req.params.id },
       include: { posts: true }
     });
     res.json(user);
   });
   
   app.listen(3000);

   Test: curl http://localhost:3000/users

3. Now try the same with FraiseQL:

   schema.py

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

   -- Create the SQL view (write once)
   CREATE VIEW v_user AS
   SELECT u.id,
       jsonb_build_object(
           'id',    u.id::text,
           'email', u.email,
           'name',  u.name,
           'posts', COALESCE(
               jsonb_agg(jsonb_build_object('id', p.id::text, 'title', p.title))
               FILTER (WHERE p.pk_post IS NOT NULL),
               '[]'::jsonb
           )
       ) AS data
   FROM tb_user u
   LEFT JOIN tb_post p ON p.fk_user = u.pk_user
   GROUP BY u.pk_user, u.id;

   fraiseql run
   
   # GraphQL API is ready - no REST endpoints to write
   curl -X POST http://localhost:8080/graphql \
     -H "Content-Type: application/json" \
     -d '{"query": "{ users { name posts { title } } }"}'

4. Compare N+1 handling:

   With Prisma, you must remember include:

   // Without include: N+1 queries!
   const users = await prisma.user.findMany();
   for (const user of users) {
     user.posts = await prisma.post.findMany({ where: { authorId: user.id } });
   }

   With FraiseQL, N+1 is impossible — the view already JOINs the data.

5. Compare deployment complexity:

   Prisma deployment:

   • Node.js runtime
   • Express/Fastify server
   • Prisma Client
   • Database connection pool management
   • Your custom API code

   FraiseQL deployment:

   • Single Rust binary
   • Pre-built SQL views
   • That’s it

Using Them Together

You can use Prisma’s migration tooling alongside FraiseQL’s API server:

# Use Prisma Migrate for database schema management
prisma migrate dev

# Use FraiseQL to serve the GraphQL API
fraiseql run

Tip

This combination is popular: Prisma’s migration tooling is excellent for managing schema changes, while FraiseQL handles serving the GraphQL API from hand-optimized SQL views.

Or use FraiseQL for your customer-facing GraphQL API and Prisma for admin/internal tools.

Migration from Prisma

1. Convert Schema

   Prisma

   model User {
     id    String @id @default(uuid())
     name  String
     posts Post[]
   }

   FraiseQL

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

2. Write SQL Views to Replace the API Layer

   Your Express/Fastify routes are replaced by the GraphQL API. Each query maps to a PostgreSQL view that you write and control.

   CREATE VIEW v_user AS
   SELECT u.id,
       jsonb_build_object(
           'id',    u.id::text,
           'name',  u.name,
           'posts', COALESCE(
               jsonb_agg(jsonb_build_object('id', p.id::text, 'title', p.title))
               FILTER (WHERE p.pk_post IS NOT NULL),
               '[]'::jsonb
           )
       ) AS data
   FROM tb_user u
   LEFT JOIN tb_post p ON p.fk_user = u.pk_user
   GROUP BY u.pk_user, u.id;

3. Move Business Logic to PostgreSQL Functions

   Complex route handlers become PostgreSQL functions (fn_*), or use FraiseQL’s observer pattern to react to data changes:

   fraiseql.toml

   [observers]
   backend = "nats"
   nats_url = "nats://localhost:4222"
   
   [[observers.rules]]
   entity = "Order"
   event = "UPDATE"
   condition = "status = 'pending'"
   
   [[observers.rules.actions]]
   type = "webhook"
   url = "https://payments.internal/process"
   
   [observers.rules.actions.body]
   order_id = "{id}"
   amount = "{total}"

Summary

Choose	When
Prisma	You want an ORM, building REST, need MongoDB, want full control over application code
FraiseQL	You want GraphQL, less application code, guaranteed N+1 prevention, Rust-level performance

Prisma is a database client. FraiseQL is a complete GraphQL API server.

Prisma Migration Guide

Step-by-step guide to migrate from Prisma to FraiseQL.

Read guide

Getting Started

Learn FraiseQL fundamentals from scratch.

Read guide

Schema Concepts

Understand SQL views, types, and decorators in depth.

Read guide

All Comparisons

See how FraiseQL compares to other tools.

Compare vs Apollo