Skip to content
DB Design

DDL Builder

Design tables visually and generate CREATE TABLE statements (MySQL / PostgreSQL / SQLite) together with an ER diagram. You can also paste a JSON sample to infer columns automatically. Everything runs in your browser — nothing you enter is sent anywhere.

Guide: How to use & features

  • Paste an object or array as JSON into "Generate from JSON" to add a table with column types, primary key, and NOT NULL already inferred.
  • In "Table design" you can edit the table name, column names, types, PK/NOT NULL/UNIQUE/auto-increment, and default values directly.
  • In "Relations", pick a from-table/column and a to-table/column to add a foreign key constraint and its connecting line in the ER diagram.
  • Choose a dialect (MySQL / PostgreSQL / SQLite) and click "Generate DDL" to get CREATE TABLE statements formatted for that dialect.
  • Click "Open in SQL Builder" to hand off the generated DDL directly to the Visual SQL Builder and continue building queries.

FAQ: FAQ

  • How do types differ between MySQL, PostgreSQL, and SQLite?

    Tables are stored internally with shared logical types (INTEGER, DECIMAL, VARCHAR, etc.) and only converted to each database's real types when you generate DDL. For example, BOOLEAN becomes INTEGER on SQLite (which has no boolean type), and an auto-increment primary key becomes AUTO_INCREMENT on MySQL, SERIAL on PostgreSQL, and INTEGER PRIMARY KEY AUTOINCREMENT on SQLite.
  • What happens to NOT NULL, UNIQUE, and the default value when a column is marked PK?

    A primary key is NOT NULL and UNIQUE by definition, so once a column is marked PK, its NOT NULL/UNIQUE/default settings are ignored — it's emitted as just "TYPE PRIMARY KEY" (plus AUTO_INCREMENT/SERIAL/etc. if auto-increment is on).
  • How does generating from JSON handle nested data?

    A top-level property whose value is an array of objects is automatically split into its own table with a foreign key back to the parent (e.g. an order and its line items). A nested plain object becomes a JSON-typed column instead. Nesting deeper than one level isn't split automatically, so adjust those cases by hand.
  • Can I use the generated DDL directly in a production migration?

    This tool is meant as a starting point for table design or a review artifact — it doesn't generate indexes, CHECK constraints, character sets/collations, or partitioning, which real deployments usually need. Always review the output and adjust it before using it in production.

Use cases: Common use cases

  • Sketching out tables for a new API or service

    Assemble the tables and columns you need visually in the early stages of a project and export them directly as CREATE TABLE statements.

  • Reverse-engineering a DB schema from an existing JSON response

    Paste a JSON sample from an API response or log entry to auto-generate a matching table layout and DDL as a starting point.

  • Producing an ER diagram for a team design review

    See the table structure you designed rendered instantly as a Mermaid ER diagram, useful for aligning on a design during review.

  • A full design-to-query workflow with sql-to-er / SQL Builder

    Hand the generated DDL off to SQL Builder to start building queries, or paste it back into sql-to-er later to double-check the structure — the whole flow from design to querying stays in the browser.

Notes: Notes & limitations

  • Generated DDL only covers basic constraints

    PRIMARY KEY, NOT NULL, UNIQUE, DEFAULT, and FOREIGN KEY are supported, but indexes, CHECK constraints, character sets/collations, and partitioning are not generated. Always review the output before using it in a production migration.

  • Type inference from JSON depends on your sample

    Types can only be inferred from the values present in the sample you provide. If a column can realistically hold other types of values too, adjust the inferred type by hand.

  • Table and column names aren't checked against reserved words

    Naming a table or column after a reserved word (like "order" or "group") won't trigger a warning here. If the generated DDL fails to run, check for a name collision first.

Generate from JSON (optional)

Table design

Relations (foreign keys)

DDL output

ER diagram preview

Articles for this tool

Recent Articles

Use Case
2026-08-07

curl Options Cheat Sheet: What -X, -H and -d Actually Do

A reference for the curl options you meet in real API work: why -d already implies POST, how -d differs from --data-raw, the @ prefix that silently reads a file, single vs double quotes, and why -k and -L deserve more caution than they usually get.

Introduction
2026-08-06

Converting Between JSON Schema and Zod: How required Maps to .optional()

Inside a two-way converter that turns JSON Schema into a Zod schema and Zod code back into JSON Schema. Covers the inverted defaults between required and .optional(), the constraint mapping table, and how the Zod side is parsed without executing any code.

Use Case
2026-08-06

SQL Clause Order Reference: Why WHERE Can't See Your SELECT Alias

The order you write SQL clauses is not the order the database runs them. A reference for the logical execution order (FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT), why aliases fail in WHERE, when to use WHERE vs HAVING, and the MySQL/PostgreSQL differences that bite.

Use Case
2026-08-06

UTC to JST Reference: The 9-Hour Offset, Cheat Sheet & Timezone Pitfalls

Convert between UTC and JST (Japan Standard Time) with a cheat sheet. Covers what Z and +09:00 mean in ISO 8601, when JavaScript date parsing silently shifts by 9 hours, MySQL/PostgreSQL timezone behavior, and why GitHub Actions cron always runs in UTC.

Use Case
2026-08-06

Unified Diff Format Reference: Reading @@ Hunks in git diff Output

How to read the unified diff format git produces: what the four numbers in @@ -12,7 +12,9 @@ mean, why a one-character edit shows as a whole-line replacement, the whitespace and line-ending traps, \ No newline at end of file, combined @@@ diffs on merges, and rename detection via similarity index.

Use Case
2026-08-04

CREATE TABLE Reference: MySQL vs PostgreSQL vs SQLite Types & Constraints

A cross-database CREATE TABLE (DDL) reference with cheat sheets for data types, auto-increment keys (AUTO_INCREMENT / IDENTITY / rowid), foreign key ON DELETE behavior, and the CHECK constraint that MySQL silently ignores.

Ad

Ad