Why SQLAlchemy 2.0 conversion is different
SQLAlchemy 2.0 encourages typed declarative models with Mapped[] annotations and mapped_column() declarations. That means a converter should not simply translate SQL text into old-style Column assignments. It needs to understand enough of the table definition to choose Python types, SQLAlchemy column types, nullability, primary keys, and ForeignKey references.
PostgreSQL DDL also carries information that does not map one-to-one into ORM code. A DEFAULT expression may be safe as a server default, a complex CHECK constraint may need a manual model-level decision, and a quoted identifier may be valid SQL while still being awkward as a Python attribute. A good conversion workflow should generate a strong starting point and make unsupported pieces visible.
A safe workflow for generated ORM models
Start with one table at a time when you are validating a schema. Paste the CREATE TABLE statement into the local converter, generate the model, and immediately read the warning comments. The warnings are not noise: they tell you where a human should decide whether to preserve, rewrite, or ignore a SQL-specific construct.
After generation, run the model through your formatter and type checker. Then add relationships, indexes, naming conventions, and server defaults according to your project style. The generated class should save time on the repetitive mapping work, not replace schema review.
Common PostgreSQL type mappings
Integer, bigint, smallint, boolean, text, varchar, numeric, timestamp, date, uuid, json, and jsonb are usually straightforward. Numeric columns should map to Decimal at the Python layer, timestamps should import datetime, and UUID columns should import UUID from the standard library.
Unknown or project-specific database types should become Any with a warning. That is intentionally conservative. Guessing a precise Python type for an extension type can create false confidence and subtle bugs in validation, serialization, or migrations.
Use the embedded converter
The converter below runs locally in your browser. It does not upload DDL, table names, comments, or generated model code. Paste a CREATE TABLE statement, generate the model, and copy the output into a scratch file for review.