SQL to GraphQL Schema Generator

The problem with writing GraphQL types by hand

You have a SQL schema with 20 tables. Your backend team wants a GraphQL API. Someone sits down and writes the SDL by hand — copying column names, converting VARCHAR(255) to String, BOOLEAN to Boolean, UUID to ID. Then the database schema changes and the SDL is already out of date.

SchemaForge converts SQL DDL to GraphQL SDL automatically. Each table becomes a type. Column types map to GraphQL scalars. ENUMs become GraphQL enums. Nullable columns become optional fields. Review the generated output before use, especially relationship details: the shared representation does not retain foreign-key constraints or ORM relationship fields.

Quick start

1 — Install

# Install from GitHub (PyPI publishing pending)
pip install git+https://github.com/Coding-Dev-Tools/schemaforge.git

2 — Convert your SQL file

schemaforge convert --from sql --to graphql --input schema.sql --output schema.graphql

3 — Check the output

# schema.graphql — generated from your SQL DDL
type User {
  id: ID!
  email: String!
  name: String
  role: UserRole!
  createdAt: String
}

enum UserRole {
  admin
  member
  viewer
}

type Post {
  id: ID!
  authorId: ID!
  title: String!
  body: String
  publishedAt: String
}

Each SQL table maps to a GraphQL type. NOT NULL columns become non-nullable fields (!). PRIMARY KEY UUID columns map to ID. ENUM columns generate a separate enum type. Function defaults like CURRENT_TIMESTAMP and gen_random_uuid() survive the conversion.

Type mapping reference

SchemaForge maps SQL column types to GraphQL scalars using a shared internal representation. Here's how the common types convert:

More conversion examples

Generate GraphQL from a Prisma schema

schemaforge convert --from prisma --to graphql --input schema.prisma --output schema.graphql

Convert GraphQL back to SQL DDL

# Bidirectional — graphql → sql is fully supported
schemaforge convert --from graphql --to sql --input schema.graphql --output schema.sql

Batch convert a directory of SQL files

schemaforge check --dir ./schemas/ --canonical sql
# Checks all schema files in the directory for consistency
# Use with --canonical to verify all formats roundtrip through a single source of truth

Diff two versions of your schema

# Catch breaking changes before they land in production
schemaforge diff schema-v1.sql schema-v2.sql
# Reports added/removed/modified tables, columns, indexes, and constraints

CI integration

Add schema consistency checks to your CI pipeline to catch drift early:

# .github/workflows/schema-check.yml (excerpt)
- name: Check schema consistency
  run: |
    pip install git+https://github.com/Coding-Dev-Tools/schemaforge.git
    schemaforge diff schemas/current.sql schemas/expected.sql
    schemaforge check --dir schemas/

schemaforge diff exits non-zero when it finds differences, so the job fails if the schemas diverge. Pair it with the check command to verify consistency across all formats in a directory.

VS Code extension

The SchemaForge VS Code extension lets you preview your schema converted to all 11 formats in a side panel as you edit. Open any .sql, .prisma, or .graphql file and run SchemaForge: Show Preview from the command palette to see the GraphQL SDL output live.

How SchemaForge compares

Comparison based on public documentation as of June 2026. Verify current feature sets before making tool decisions.

Supported conversion scope

SchemaForge supports 11 formats and 100 documented conversion directions. Alembic is output-only. Tables, columns, types, defaults, indexes, unique constraints, and enums are preserved by the shared representation; review foreign-key constraints and ORM relationship fields after conversion because they are not retained.