SQL to TypeORM Entities

Paste CREATE TABLE SQL and get ready-to-use TypeORM entity classes in TypeScript. The converter applies the right decorator for each column: @PrimaryGeneratedColumn() for auto-increment PKs, @CreateDateColumn() and @UpdateDateColumn() for conventional timestamp columns, @Column() with type, length, nullable, and unique options for everything else, plus FK relation hints as comments.

How to use the SQL to TypeORM Entities

Paste one or more CREATE TABLE SQL statements (separate multiple statements with semicolons) into the input. Click Generate Entities. One TypeORM entity class is generated per table.

The converter detects auto-increment primary keys (SERIAL, AUTO_INCREMENT) and uses @PrimaryGeneratedColumn(). Non-auto-increment PKs get @PrimaryColumn(). For timestamp columns whose names match created_at / updated_at / deleted_at patterns, the converter emits @CreateDateColumn(), @UpdateDateColumn(), or @DeleteDateColumn() respectively. Regular columns get @Column({ type, length, nullable, unique, default }) with options filled from the SQL definition.

Foreign key constraints are parsed and added as comments below the relevant column showing the @ManyToOne + @JoinColumn boilerplate — you fill in the cardinality and enable the import. The Example button loads a two-table schema with a FK, timestamps, and a soft-delete column so you can see the full range of outputs before pasting your own SQL.

What is TypeORM?

TypeORM is the most popular ORM for TypeScript and Node.js. It uses the Active Record and Data Mapper patterns and integrates deeply with TypeScript decorators — each database table maps to a class decorated with @Entity, each column to a class property decorated with @Column or a specialised variant. TypeORM supports PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, and MongoDB, making it a go-to choice for projects that need to target multiple databases.

Writing TypeORM entities by hand from an existing schema is repetitive and error-prone — every column needs the right @Column options to match the database type and constraints. The type option must be a driver-specific string like "varchar" or "timestamp", nullable must be explicitly set to true for optional columns, and unique constraints must be flagged separately. Getting any of these wrong causes silent truncation, validation errors, or runtime type mismatches.

The smart decorators like @CreateDateColumn and @UpdateDateColumn go further: they automatically set the value server-side on insert or update, which means your application code does not need to set those fields manually. This converter detects column names that follow the created_at/updated_at convention and applies those decorators automatically, saving a common source of bugs in new TypeORM projects.

Common use cases

  • Database-first development — generate TypeORM entities from an existing production database schema without writing boilerplate by hand.
  • Schema migrations — when adding a new table, write the SQL DDL first, convert to a TypeORM entity, and integrate it into your project.
  • Cross-ORM comparison — use this alongside the SQLAlchemy generator to compare how the same schema looks in different ORM ecosystems.
  • Code review support — share the TypeScript entity with TypeScript developers for review while the DBA reviews the SQL DDL.
  • Learning TypeORM — see the direct mapping between SQL column types and TypeORM decorator options for common types you use every day.

Frequently asked questions

Does it generate relationship() decorators?
FK constraints are emitted as commented @ManyToOne + @JoinColumn blocks below the scalar column. You need to uncomment them, add the import for the referenced entity class, and decide whether to add the @OneToMany inverse side.

How does it decide between @CreateDateColumn and @Column for timestamps?
If the column name matches created_at, createdAt, created_on, or similar patterns AND the SQL type is TIMESTAMP or DATETIME, the converter uses @CreateDateColumn. Same logic for updated_at → @UpdateDateColumn and deleted_at → @DeleteDateColumn. For all other timestamp columns it uses a plain @Column.

What TypeORM version is the output compatible with?
The output targets TypeORM 0.3.x (the current release line). The decorator API has been stable since 0.2.x so the entities also work with 0.2.x projects.

Does it support composite primary keys?
Yes — table-level PRIMARY KEY (col1, col2) is parsed and @PrimaryColumn() is applied to each named column. TypeORM supports composite PKs through multiple @PrimaryColumn decorators on the same entity.

Is the output production-ready?
The entity skeletons are correct and can be used directly, but you should review nullability (TypeORM defaults to nullable: false), add relations() for FK relationships, and add any custom validation using class-validator if your project uses it.