Trade-Offs

The Problem

FraiseQL compiles views at deploy time. If you're rapidly changing your schema multiple times per day, you'll need to redeploy for each change.

This means: Deploy cycle for every schema change. Not great for early-stage startups doing rapid experimentation.

Better Alternatives

• Hasura - Schema inference from database (changes reflected immediately)
• PostGraphile - Auto-generates schema from database structure
• Apollo with resolvers - Runtime flexibility, no recompilation needed

When FraiseQL Still Works

• You've stabilized your schema (post-MVP)
• Schema changes are planned and infrequent
• Your deployment pipeline is automated

The Problem

FraiseQL views are pre-defined. Each view is a specific query composition.

If you need completely flexible, user-defined queries (like building a reporting tool), FraiseQL requires a view for each possible query combination.

Better Alternatives

• Metabase/Superset - Ad-hoc query builders with caching
• Cube.js - Semantic layer for analytics
• Traditional GraphQL - Field resolvers provide flexibility
• REST API - Simple, flexible for reporting

When FraiseQL Still Works

• You know the queries developers need (dashboards, reports, etc.)
• You can predict data composition patterns
• You have a finite set of common queries

The Problem

FraiseQL moves logic to the database (SQL views). This works great for data composition.

But if you need complex application logic (business rules, integrations, workflows), FraiseQL keeps that in resolvers—which then defeats the "no N+1" advantage if those resolvers fetch additional data.

Better Alternatives

• Traditional GraphQL - Resolvers give you full control over logic
• REST API - Better for complex business logic workflows
• gRPC - Type-safe, efficient for complex services

When FraiseQL Still Works

• Most of your logic is data composition (not business logic)
• You can push logic to the database layer
• You don't need external service integrations in resolvers

The Problem

FraiseQL requires upfront schema planning. You need to:

• Design your database schema
• Write SQL views
• Define types in your framework
• Compile and deploy

For a quick MVP where you don't know what you're building, this overhead might be too much.

Better Alternatives

• Firebase/Supabase - Fastest path to MVP
• Hasura - Auto-generates API from schema
• Apollo + Node.js - Rapid development with resolvers

When FraiseQL Still Works

• You have a clear data model in mind
• Your MVP is past the validation stage
• You're ready to build for scale

The Problem

FraiseQL is SQL-first. It works with PostgreSQL, MySQL, MariaDB, and SQLite—databases with structured schemas and SQL support.

If you're using MongoDB, DynamoDB, or other NoSQL databases, FraiseQL doesn't apply.

Better Alternatives

• Apollo - Language-agnostic, works with any data source
• Pothos - GraphQL schema builder for TypeScript
• Strawberry - Python GraphQL with dataloader support

When FraiseQL Still Works

• You're committed to SQL databases
• You need ACID transactions and referential integrity
• Your data is relational and structured

The Problem

FraiseQL introduces an extra deployment step: view compilation.

For tiny APIs or MVPs where simplicity matters more than scale, this can feel like extra ceremony.

Better Alternatives

• Vercel Functions + Apollo - Simplest possible deployment
• Firebase Functions - Serverless GraphQL
• Hasura Cloud - Single-click deployment

When FraiseQL Still Works

• You have a mature deployment pipeline
• Your team is comfortable with compiled systems
• You're building for scale from the start