Prisma Schema Generator

Generate a Prisma schema model from any JSON sample.

Presets:

DB provider

Paste a JSON object sample

JSON Size

0 B

JSON Lines

Prisma Models

Inferred Fields

About Prisma Schema Generator

This tool reads a JSON object sample and produces a ready-to-use schema.prisma file. Field types are inferred automatically: numbers become Int or Float, booleans become Boolean, date-like strings become DateTime, and nested objects are extracted into separate related models with a foreign-key relation. Select your target database provider to set the correct datasource block. The generated schema is entirely client-side — your data never leaves the browser.

Built and maintained by Meet Shah · Last updated 13 August 2026

What this tool is used for

Generating a Prisma model from a sample document or row.
Producing a starting schema for a table that has no model yet.
Getting the attribute syntax right for ids and defaults.
Creating a model for a fixture that matches production shapes.
Comparing a generated model against an existing schema.

Frequently Asked Questions

How are field types inferred from a sample?: From each value's JSON type: boolean gives Boolean, a whole number Int, a fractional one Float, a nested object a related model plus a foreign key, an array a scalar list. String keys get extra scrutiny — an email key gains @unique, an id or …Id key becomes the key column, and a date-shaped name becomes DateTime.
Why isn't a key called format treated as a timestamp?: Because the date test is anchored to shapes that genuinely name timestamps: an …At suffix, _at, a …Date suffix, or a whole word date, time or timestamp. Testing for a key ending in the letters at typed format, chat, seat, flat and repeat as DateTime @default(now()) — columns that cannot hold their own sample.
Will String[] work on my database?: On PostgreSQL and MongoDB, yes — both have a native list type and prisma validate accepts it. MySQL, SQLite and SQL Server have no list type at all, and the generator emits a comment saying so for those providers. The usual alternatives are a Json column or a separate related model.
What does a string id produce?: String @id, plus @default(uuid()) when the sample value is genuinely UUID-shaped. autoincrement() belongs to integer keys only; on a string column it yields a schema that cannot store the value it came from. Foreign keys copy the referenced model's id type too — Prisma rejects a relation whose scalar types disagree.
Which shapes does the inference get wrong?: An array of objects becomes String[] rather than a one-to-many relation, because arrays are classified before their contents are examined. Back-relations pluralise by appending an s, so Address becomes addresss, and a snake_case key keeps its underscore. Treat the output as a first draft, not a migration.

Common errors and gotchas

Accepting an inferred type where Prisma's own type system is stricter than the sample suggests.
Generating a scalar where a relation was intended, which loses referential integrity.
Letting a date string become `String` rather than `DateTime`, which breaks range queries.
Omitting `@unique` and indexes, which are cheap now and painful on a large table later.
Shipping a model without a migration, so the schema and the database drift apart.