CREATE TABLE Generator for Four SQL Dialects

One table, four genuinely different statements

Below is the same five-column users table — an auto-incrementing key, a unique email carrying a comment, a status with a text default, a boolean flag and a created timestamp — as each of the four dialects wants it written. Nothing about the design changed. Almost every line did.

CREATE TABLE IF NOT EXISTS "users" (
    "id" BIGINT GENERATED ALWAYS AS IDENTITY,
    "email" VARCHAR(255) NOT NULL UNIQUE,
    "status" VARCHAR(20) NOT NULL DEFAULT 'active',
    "is_active" BOOLEAN NOT NULL,
    "created_at" TIMESTAMPTZ NOT NULL DEFAULT NOW(),
    CONSTRAINT "pk_users" PRIMARY KEY ("id")
);

COMMENT ON COLUMN "users"."email" IS 'Login identity';

CREATE TABLE IF NOT EXISTS `users` (
    `id` BIGINT NOT NULL AUTO_INCREMENT,
    `email` VARCHAR(255) NOT NULL UNIQUE COMMENT 'Login identity',
    `status` VARCHAR(20) NOT NULL DEFAULT 'active',
    `is_active` TINYINT(1) NOT NULL,
    `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT `pk_users` PRIMARY KEY (`id`)
);

CREATE TABLE IF NOT EXISTS "users" (
    "id" INTEGER PRIMARY KEY AUTOINCREMENT,
    "email" TEXT NOT NULL UNIQUE,  -- Login identity
    "status" TEXT NOT NULL DEFAULT 'active',
    "is_active" INTEGER NOT NULL,
    "created_at" TEXT NOT NULL DEFAULT (datetime('now'))
);

IF OBJECT_ID(N'[users]', N'U') IS NULL
BEGIN
    CREATE TABLE [users] (
        [id] BIGINT IDENTITY(1,1) NOT NULL,
        [email] NVARCHAR(255) NOT NULL UNIQUE,  -- Login identity
        [status] NVARCHAR(20) NOT NULL DEFAULT 'active',
        [is_active] BIT NOT NULL,
        [created_at] DATETIME2 NOT NULL DEFAULT SYSUTCDATETIME(),
        CONSTRAINT [pk_users] PRIMARY KEY ([id])
    );
END;

Count the differences: three quoting styles, four auto-increment spellings, four boolean representations, four timestamp types, two places a column comment can live, and one dialect that cannot say IF NOT EXISTS at all. That is why a snippet from a PostgreSQL answer on Stack Overflow rarely survives contact with MySQL.

The type translation table

This is the mapping the generator applies when you switch dialects. It is worth keeping around even when you are writing the SQL by hand — the rows that surprise people most are boolean, JSON and UUID.

Two rows deserve a footnote. SQLite’s column looks lazy because SQLite uses type affinity: VARCHAR(50), DATE and DATETIME are all accepted, all stored as text, and the length is never enforced — the declared type is mostly documentation. And MySQL’s CHAR(36) UUID costs 36 bytes per row where PostgreSQL and SQL Server store 16; if the table gets large, consider BINARY(16) with UUID_TO_BIN() instead of what this tool emits.

Quoting, auto-increment, and the clauses that do not exist

These three columns break more pasted SQL than the types do, because they break on line one rather than line nine.

The generator handles each of these for you rather than pretending they are the same. Tick IF NOT EXISTS on SQL Server and it wraps the whole statement in IF OBJECT_ID(N'[users]', N'U') IS NULL BEGIN … END;, and says so in a note. Ask for AUTOINCREMENT on a SQLite table whose key is a BIGINT, or part of a composite key, and it drops the keyword and explains why — SQLite requires the literal words INTEGER PRIMARY KEY AUTOINCREMENT on one column. Turn the index block on for MySQL or SQL Server and it warns that re-running those CREATE INDEX statements will error, because neither accepts IF NOT EXISTS there. Rerunnable migrations are a per-dialect problem, not a checkbox.

Why the default value has an “expr” toggle

A default is either data or SQL, and the database cannot tell which you meant from the characters alone. DEFAULT 'active' stores six letters. DEFAULT CURRENT_TIMESTAMP calls a function every time a row is inserted. Same slot in the grammar, completely different behaviour — which is why each column here has a small toggle that flips between 'text' and expr.

Guessing wrong fails in two different ways, and only one of them is loud:

• Quoting something that should be an expression gives you DEFAULT 'CURRENT_TIMESTAMP'. On a date column that errors immediately. On a text column it succeeds — and every row silently gets the literal string CURRENT_TIMESTAMP. You find out weeks later.
• Leaving a literal unquoted gives you DEFAULT active, which the parser reads as an identifier, not a word. That one at least fails at CREATE TABLE time.

The tool nudges you when the two disagree: type 0 or NOW() into a quoted default and it offers to switch the column to an expression, and vice versa. It also flags booleans — SQLite and SQL Server have no TRUE / FALSE keyword in a default, so those want 1 and 0. And when you enable the timestamps helper it writes a different expression per dialect: NOW() on PostgreSQL, CURRENT_TIMESTAMP on MySQL, (datetime('now')) on SQLite, SYSUTCDATETIME() on SQL Server. Only MySQL can keep updated_at fresh from the column definition itself, with ON UPDATE CURRENT_TIMESTAMP; the other three need a trigger or an explicit assignment in every UPDATE, and the tool says so instead of quietly leaving you with a column that never changes.

Choosing the primary key type

This is the one decision on the page that is genuinely hard to reverse, so it is worth two minutes before you tick the auto-increment box.

A bigint identity key is eight bytes, sorts in insert order, is trivial to read in a log line, and is the right default for a single database. Its costs are real but narrow: ids can only be minted by the database, so you cannot generate one client-side before the insert; and the numbers are guessable, so exposing /orders/1042 in a URL tells the world roughly how many orders you have taken.

A UUID key fixes exactly those two problems and charges you for it. It is 16 bytes natively — 36 as CHAR(36) on MySQL — and every secondary index carries a copy. The bigger cost is ordering: a random UUID v4 lands in a different place in the index on every insert, which is painful in MySQL InnoDB and SQL Server where the table is physically stored in primary key order. If you want UUIDs, use the time-ordered UUID v7, which puts a millisecond timestamp in the leading bits so new rows still append to the end of the index. Our UUID generator goes into the v4 versus v7 trade-off properly and will produce either.

A practical middle path many teams settle on: keep the bigint identity as the internal primary key and add a separate indexed UUID column as the public identifier. You pay for one extra index instead of paying on every index, and nothing in your URLs leaks row counts. Whichever you pick, tick more than one column as Primary key here and the generator emits a composite CONSTRAINT "pk_table" PRIMARY KEY (a, b) — the normal shape for a join table.

What this generator does not do

The output is a starting point, not validated SQL. Read it before you run it against a real database — ideally run it against a scratch one first. Concretely:

• Nothing is parsed or executed. The statement is assembled as text and never checked for correctness, so a typo in a default expression sails straight through.
• Versions differ. Identity columns need PostgreSQL 10 or newer, DROP TABLE IF EXISTS needs SQL Server 2016 or newer, and MySQL and MariaDB have drifted apart. The dialect picker has no version picker.
• No foreign keys, check constraints, partitioning or storage options. It builds columns, one primary key, unique flags, defaults, comments and simple single-column indexes. Anything else you add by hand.
• DROP TABLE really drops the table. The optional drop line destroys the existing table and every row in it, with no undo. The tool warns you; the database will not.
• Comments are not portable. MySQL stores them inline and PostgreSQL via COMMENT ON COLUMN. SQLite has no column comments at all, and SQL Server keeps descriptions in extended properties, so for those two your text is emitted as -- comments that the schema does not retain.
• Nothing leaves your browser. No database is ever contacted, no connection string is asked for, and your column names are not uploaded anywhere. This tool only generates text, and there are no accounts and no saving.

Frequently asked questions