JSON to SQL Schema

Infer a CREATE TABLE statement from a JSON object or an array of objects. The tool inspects every record, works out each column's type — integer, floating point, boolean, date, timestamp, UUID, or nested JSON — and emits DDL for PostgreSQL, MySQL, or SQLite. Columns that are always present become NOT NULL, an id column can be promoted to a primary key, and string lengths are sized from the data. All in your browser.

schema.sql

How to use the JSON to SQL Schema

Paste a single JSON object or — better — an array of objects, since more rows give the type inference more to work with. Pick your database dialect, set a table name, and the CREATE TABLE regenerates live. Each key becomes a column whose type is inferred from the values across all records: whole numbers become integers, decimals become floating point, true/false become the dialect's boolean type, ISO dates and timestamps are recognised, UUID strings map to a UUID column, and nested objects or arrays become the dialect's JSON type.

Two toggles shape the constraints. NOT NULL where present marks a column required only when every record has a non-null value for it, so optional fields stay nullable. id as PRIMARY KEY promotes an integer id column to the primary key. Columns named id or ending in _id are widened to BIGINT for safety. Treat the output as a strong first draft — review types, add indexes and foreign keys, and adjust string lengths before running it in production.

Inferring a schema from data

When you have JSON from an API, a NoSQL export, or a log and want to land it in a relational database, the first chore is writing the CREATE TABLE. Doing it by hand means eyeballing every field and guessing types. Inferring the schema from the actual data is faster and more accurate, because the values themselves reveal whether a field is always an integer, sometimes null, or occasionally a decimal that forces a floating-point column.

The inference looks at every record, not just the first, which matters because real data is irregular. A field that's 7 in one row and 7.5 in another must be a floating-point column, not an integer. A field present in some records and missing in others should be nullable. Strings are inspected for recognisable shapes — an ISO date, an ISO timestamp, or a UUID — and mapped to dedicated column types where the dialect has them, falling back to a VARCHAR sized to the longest observed value or to TEXT when values are long or unbounded. Objects and arrays become the native JSON type: JSONB in PostgreSQL, JSON in MySQL, and TEXT in SQLite, which has no JSON type but stores it as text.

The dialects differ in ways the generator handles for you. PostgreSQL has true BOOLEAN, UUID, and JSONB types; MySQL represents booleans as TINYINT(1) and UUIDs as CHAR(36); SQLite uses its small set of storage classes, so almost everything collapses to INTEGER, REAL, or TEXT. Inferred schemas are a starting point, not a final design — they capture types and nullability well, but indexes, foreign keys, defaults, and precise numeric precision are decisions only you can make.

Common use cases

  • Loading API data. Generate a table to store responses you're about to ingest.
  • NoSQL to SQL migration. Draft relational schemas from MongoDB or Firestore document exports.
  • Quick analytics. Stand up a table for a JSON dataset you want to query with SQL.
  • Schema scaffolding. Skip the boilerplate and start from inferred types, then refine.

Frequently asked questions

Should I paste one object or many?
Many, when you can. Type inference looks across every record, so an array of objects produces more accurate types and nullability than a single object. A single object works too — it just has less evidence to reason from.

How are string lengths chosen?
For PostgreSQL and MySQL, a VARCHAR is sized to the next power of two above the longest observed value (capped at 255); longer values become TEXT. SQLite ignores declared lengths, so strings always map to TEXT.

What happens with nested objects and arrays?
They map to the dialect JSON type — JSONB on PostgreSQL, JSON on MySQL, TEXT on SQLite. The tool does not flatten nested structures into separate tables; if you need normalisation, split the data first.

Does it add indexes or foreign keys?
No. It infers columns, types, nullability, and an optional id primary key. Indexes, foreign keys, unique constraints, and defaults are design decisions specific to your application, so add them after reviewing the generated DDL.

Is the data uploaded?
No. Parsing and DDL generation run entirely in your browser. Nothing is sent to a server, so sensitive records stay local.