MSRX Tools

SQL to TypeScript

Turn CREATE TABLE statements into typed row interfaces.

Everything runs inside your browser. Your files never leave your device.

Input

Result

The result appears here as you type.

Ask about SQL to TypeScript

Questions about what this tool does, which option to pick, or what it can and cannot handle.

The question you type here is sent to an AI provider to be answered — your files and whatever you put in the tool above are not, and the assistant cannot see them. Answers are generated and can be wrong. The tool itself is not guessing: it runs deterministic code on your device.

About the SQL to TypeScript

Hand-writing a TypeScript interface for a database table is copying, and copying drifts. A column gets added in a migration, the interface does not, and the mismatch surfaces at runtime in whatever code assumed the field was there. This converts CREATE TABLE statements straight into typed row interfaces.

Paste your DDL and it produces one interface per table, named from the singularised table name, with columns mapped to TypeScript types and nullability worked out from the constraints. It reads MySQL, PostgreSQL, SQLite and SQL Server syntax, skips table-level constraints such as PRIMARY KEY and UNIQUE clauses rather than turning them into properties, and carries a column comment through as a doc comment.

Two mapping decisions are deliberate and worth knowing. BIGINT becomes string, not number, because a 64-bit integer does not fit in a JavaScript number and every serious driver returns it as a string to avoid silently losing precision at 2^53. Typing it as number would be a lie the compiler cannot catch, and would fail on exactly the large identifiers where correctness matters most. Second, DATE and TIMESTAMP default to string, which is what most drivers actually hand back — switch to Date only if your ORM parses them for you.

Nullability comes from three signals rather than one. NOT NULL means the column cannot be null. PRIMARY KEY means the same even when the DDL leaves NOT NULL implicit, which many dialects do. A DEFAULT clause means the column always has a value once a row exists. Everything else is treated as nullable, rendered either as an optional property or as a union with null, whichever your codebase prefers.

The output still deserves a read. Columns your application fills in — created_at, updated_at, soft-delete flags — are often typed as always-present when the insert type should treat them as optional.

How to use it

  1. 1Paste your CREATE TABLE statements, including the trailing semicolons that mark where each ends.
  2. 2Choose the property naming convention — camelCase for most codebases, or exactly as in the database if you query it directly.
  3. 3Pick how nullable columns should read: an optional property, or a union with null.
  4. 4Check the generated nullability against how your application actually inserts rows before relying on it.

Questions

Why is my BIGINT column typed as string?
Because 64-bit integers exceed what a JavaScript number can hold exactly. Drivers return them as strings to avoid silent precision loss above 2^53, so string is the honest type. Change it only if you know your values stay small.
Which SQL dialects does it read?
MySQL, PostgreSQL, SQLite and SQL Server. Backtick, double-quote and square-bracket identifier quoting are all handled, as are the common type spellings each dialect prefers.
How is nullability decided?
NOT NULL, PRIMARY KEY and DEFAULT each mark a column as always having a value. Anything without one of those is treated as nullable. That matches how the database behaves, though it may not match how your insert code behaves.
It only found some of my columns.
Check that each statement ends with a semicolon — that is what marks the end of a table. Table-level constraints such as UNIQUE KEY and FOREIGN KEY clauses are skipped deliberately, since they are not columns.