What does the YAML output look like?

A table key with the table's name, and a columns list where each entry has a name, a type (including any parenthesized precision like VARCHAR(255)), and a constraints list capturing anything else on that column's definition (PRIMARY KEY, NOT NULL, UNIQUE, DEFAULT , REFERENCES ..., CHECK(...)). Table-level constraints (a standalone PRIMARY KEY(...) or FOREIGN KEY(...) line) are collected separately under tableConstraints.

What SQL dialect does this support?

A reasonable, dialect-agnostic subset: standard CREATE TABLE name (columns...) syntax, with or without IF NOT EXISTS, common column-level constraints, and simple parenthesized type precision. Dialect-specific extensions (MySQL's ENGINE=... clause, Postgres's generated column syntax, computed/virtual columns) aren't parsed.

Can I paste multiple CREATE TABLE statements at once?

No, this tool expects exactly one CREATE TABLE statement per conversion. Paste multiple table definitions one at a time if you need to convert a whole schema file.

How are column constraints detected?

After the column's type is identified, the remaining text on that column's definition is scanned for recognized constraint phrases (PRIMARY KEY, NOT NULL, UNIQUE, AUTO_INCREMENT, DEFAULT followed by a value, REFERENCES followed by a table/column, and CHECK(...)), each becoming one entry in that column's constraints list, in the order they appear.

Does this tool send my SQL anywhere?

No, parsing and YAML generation both happen entirely in your browser using a hand-written parser. Nothing you paste is uploaded.

SQL to YAML - Convert CREATE TABLE Schema Online

Overview

Introduction

A CREATE TABLE statement is a compact, precise description of a table's shape, but that shape is locked inside SQL syntax that's awkward to feed into documentation generators, schema-diffing tools, or anything else that would rather read structured data. This tool extracts that shape into a YAML schema description.

It focuses specifically on the column list: names, types, and constraints, rather than trying to be a full SQL parser, so it handles the CREATE TABLE statements most real schemas actually use.

What Is SQL to YAML?

A SQL-to-YAML converter that matches the outer CREATE TABLE name (...) shape, then splits the parenthesized body on top-level commas (respecting nested parentheses inside types like VARCHAR(255) and expressions like DEFAULT NOW()), producing one segment per column or table-level constraint.

Each column segment is further split into a name, a type (with any parenthesized precision or scale attached), and a list of recognized constraint phrases, and the whole result is serialized as a YAML mapping.

How SQL to YAML Works

The statement is matched against a CREATE TABLE name (body) pattern (tolerating IF NOT EXISTS and a trailing semicolon), then body is split on commas that aren't nested inside parentheses or quotes, so a comma inside VARCHAR(255) or a quoted default value doesn't split the column list incorrectly.

Each resulting segment is checked against table-level constraint keywords (PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK, CONSTRAINT) first; anything else is treated as a column definition and split into a name, a type token (word plus optional (...) precision), and a constraints list built by matching known constraint phrases against the remaining text.

When To Use SQL to YAML

Use it to turn a CREATE TABLE statement from a migration file into a readable YAML schema for documentation.

It's also useful for quickly checking a table's column list and constraints at a glance, without parsing dense SQL syntax by eye.

Often used alongside HTML to YAML, CSV to YAML Converter and YAML Formatter & Prettifier.

Features

Advantages

Correctly splits column definitions on top-level commas even when a type or default value itself contains parentheses or commas.
Captures common constraints (PRIMARY KEY, NOT NULL, UNIQUE, DEFAULT, REFERENCES, CHECK, AUTO_INCREMENT) as a structured list per column, not just raw leftover text.
Separates table-level constraints (standalone PRIMARY KEY(...)/FOREIGN KEY(...) lines) from column-level ones.
Runs entirely client-side with no added dependency, so schema definitions never leave your browser.

Limitations

Only a single CREATE TABLE statement is supported per conversion; multi-statement input or ALTER TABLE statements aren't handled.
Dialect-specific extensions (MySQL table options like ENGINE=InnoDB, Postgres generated/computed columns, inline index definitions) aren't recognized and may produce a parse error or be dropped.
Constraint detection is pattern-based against a known list of phrases; a constraint written in an unusual way or a vendor-specific constraint keyword outside that list won't be captured.

Examples

A typical CREATE TABLE statement

Input

CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(255) NOT NULL, email VARCHAR(255) UNIQUE, created_at TIMESTAMP DEFAULT NOW())

Output

table: users
columns:
  - name: id
    type: INT
    constraints:
      - PRIMARY KEY
  - name: name
    type: VARCHAR(255)
    constraints:
      - NOT NULL
  - name: email
    type: VARCHAR(255)
    constraints:
      - UNIQUE
  - name: created_at
    type: TIMESTAMP
    constraints:
      - DEFAULT NOW()

Each column becomes one list entry with its name, type (including precision where present), and a structured constraints list.

Best Practices & Notes

Best Practices

Convert one CREATE TABLE statement at a time; split a multi-table schema file before pasting it in.
Double-check dialect-specific column options (like MySQL's AUTO_INCREMENT vs. Postgres's SERIAL) in the output, since only the literal keywords this tool recognizes are captured as structured constraints.
Run the result through YAML Validator afterward if you're feeding it into another tool that expects strictly valid YAML.

Developer Notes

splitTopLevel is the load-bearing helper: it walks the column-list body character by character, tracking a parenthesis depth counter and a simple string-literal state (', ", or `), only treating a comma as a column separator when depth is zero and it's outside a quoted region. Constraint extraction runs a single alternation regex (CONSTRAINT_PATTERN) against each column's leftover text and collects every match in order, rather than hand-parsing each constraint keyword separately.

SQL to YAML Use Cases

Documenting a database table's schema in YAML alongside other project documentation
Previewing a migration file's CREATE TABLE statement as a structured schema before applying it
Feeding a table's column/constraint shape into a YAML-driven code or documentation generator
Quickly comparing two versions of a table definition by eye once both are in the same structured YAML shape

Common Mistakes

Pasting more than one CREATE TABLE statement at once and expecting each to become a separate entry, only the first (and only) statement is parsed; convert them one at a time.
Expecting vendor-specific table options (ENGINE=InnoDB, TABLESPACE, etc.) after the closing parenthesis to appear in the output, they're outside the parsed column list and aren't captured.
Assuming every constraint keyword variant across every SQL dialect is recognized, only the common, listed set is; anything else is simply absent from that column's constraints list rather than causing an error.

Tips

If parsing fails, check that the statement has a single, complete, comma-separated column list inside one pair of parentheses.
Use Sort YAML afterward if you want the columns list re-ordered (note: sorting a list of objects isn't done automatically, since column order is usually meaningful).
For a quick sanity check, count the columns in your SQL and confirm the same number of entries appear under columns in the output.

SQL to YAML