Skip to content

SQL to Node.js App

Convert a MySQL or MariaDB dump into a Prisma schema, TypeScript factories, a seed script and Zod validation for a Node.js project, live in your browser.

Generate

Read in your browser and never uploaded. Only CREATE TABLE, ALTER TABLE and CREATE INDEX are read; INSERT data is skipped. Importing replaces the schema you are designing.

Add a table on the left, load an example, or open a project file to start designing.

Generated files

Generated files appear here as you design.

Diagnostics appear here after you paste your input.

Processed locally in your browser. Your data never leaves your device.

About this SQL to Node.js App converter

Paste the structure of a MySQL or MariaDB database and get a working start on a Node.js data layer: a Prisma schema, model factories, a seed script, and (optionally) Zod validation and TypeScript resource types. This page is the Node.js entry point of the Database Schema Studio; the schema stays fully editable once imported, and every file group can be switched on or off.

A worked example

A users table and a posts table with a foreign key on user_id produce a factory for each model:

export interface UserFactoryInput {
    name?: string
    email?: string
}

export function makeUserData(input: UserFactoryInput = {}) {
    return {
        name: input.name ?? faker.person.fullName(),
        email: input.email ?? faker.internet.email(),
    }
}

and, since posts.user_id is a required foreign key, the post factory requires it as input rather than inventing an id:

export interface PostFactoryInput {
    userId: string
    title?: string
    published?: boolean
}

Turning on Zod validation adds a matching schema, with the foreign key validated as a numeric string and the defaulted published column optional:

export const createPostSchema = z.object({
    userId: z.string().regex(/^-?\d+$/),
    title: z.string(),
    published: z.boolean().optional(),
})

export const updatePostSchema = createPostSchema.partial()

How to use it

  1. Paste CREATE TABLE statements or a structure-only dump, or open a .sql file, then Import.
  2. Choose which file groups to generate and how many rows the seed script creates.
  3. Copy or download each file, or download them all as one ZIP.

Frequently asked questions

Why Prisma, and why is the schema itself a separate output?
Prisma is the broadest-reach modern TypeScript ORM, and its schema file already is the model-and-migration layer for this stack (`prisma generate` derives the typed client from it, `prisma migrate` derives migrations from it) — there is no separate Eloquent-style model class to hand-write. Prisma schema alone is also its own page (/tools/sql-to-prisma-schema/); this page adds the factories, seed script and validation Prisma itself does not generate.
What does a factory actually produce?
A `make<Model>Data(input)` function per model, using @faker-js/faker, filling every column except ones the database computes itself (an auto-increment id, a generated column). A column with a plain default (a price, a boolean flag) still gets a real fake value — a factory’s whole point is varied data, not the same static default on every row. A required foreign key becomes a required property of `input` instead of a random id, since a random one would violate referential integrity; the seed script supplies the real one.
What does the seed script do with the factories?
Creates rows for every table with a single-column primary key, parents before children, picking an already-created parent at random for each required foreign key. A table with a composite primary key (a typical many-to-many pivot) is left out with a diagnostic rather than seeded with a guess.
How does the Zod validation relate to the resource types?
Both come from the same column list, read two different ways: the Zod schema for a request body (a column with a default becomes `.optional()`, since a caller may omit it and let the database’s default apply), the TypeScript interface for a response shape (a `password`-shaped column is left out of the resource type, though the factory still fills it — it should exist in the database, just never be echoed back).
Is my SQL uploaded?
No. Reading and generating happen in your browser. Nothing is sent anywhere or stored.
Only Express and Prisma?
Today, yes. The generator is built so a second stack (a different framework or ORM) is an added choice, not a rewrite — more are planned.