SQL to Drizzle Schema Converter

Drizzle ORM is a TypeScript ORM where the schema is plain TypeScript: every table is a pgTable, mysqlTable or sqliteTable call, and the types of your rows are inferred from it, with no code generation step. Queries look like SQL (db.select().from(users).where(eq(users.id, 1))), and a second, relational API (db.query.users.findMany({ with: { posts: true } })) loads nested data.

Its companion CLI, drizzle-kit, turns changes to that schema into SQL migrations (generate) or applies them to a database directly (push). That is why an accurate schema.ts matters: if it does not describe the tables you already have, the next push tries to "fix" the difference. This converter keeps SQL names, constraint names and defaults intact so the schema matches your database instead of only coming close.

Each dialect has its own Drizzle package, so the same SQL type can map to different builders:

A few details trip people up. numeric and decimal columns return strings by default, so money never passes through a floating-point number. bigint needs a mode: "number" is exact only up to 2^53. SQLite has no date type, so date columns become text() unless you store Unix time. Types Drizzle does not ship, such as citext or tsvector, become a small customType declared at the top of the file.

Foreign keys become real constraints first. An unnamed single-column REFERENCES turns into .references(() => users.id, { onDelete: "cascade" }) on the column. Composite or named foreign keys go into the table's extra-config array as foreignKey({ name, columns, foreignColumns }), so the constraint name in your database is preserved.

Then, with Relations on, each foreign key also produces a pair of relations() entries for the relational query API:

export const postsRelations = relations(posts, ({ one, many }) => ({
  author: one(users, {
    fields: [posts.authorId],
    references: [users.id],
  }),
  comments: many(comments),
}));

Names come from the column (author_id becomes author) and the child table (posts). When two tables are linked more than once, or a table references itself, the converter adds a relationName so Drizzle can tell the relations apart, and self-references are typed with AnyPgColumn to avoid TypeScript's circular-type error.

drizzle-kit pull introspects a live database and writes the schema for you. It is the right choice when you can connect to the database and want an exact snapshot. This converter is faster when you cannot, or do not want to:

A common workflow is to convert here, commit the schema, then run drizzle-kit generate (no database connection needed) and diff the SQL it writes against your original DDL, or drizzle-kit push to a scratch database.

It reads tables, columns, keys, indexes, enums, domains and comments. Anything else is reported in the Notes panel with a line number rather than silently dropped:

• Views, functions, triggers and policies are skipped: they are not part of a Drizzle table schema.
• CHECK constraints are kept as comments above the table, so you can turn them into check() calls if you want drizzle-kit to manage them.
• MySQL FULLTEXT indexes and prefix lengths (name(191)) have no Drizzle builder; create them in a custom migration.
• Exclusion constraints and INHERITS are PostgreSQL features Drizzle cannot express.

If your SQL is messy, run it through the SQL formatter first; the line numbers in the notes are easier to follow in tidy SQL.