Skip to main content
Use this when application code needs database types and runtime validators before the migration is applied. supaschema types reads a PostgreSQL source and emits TypeScript database types plus runtime Zod validators. The source can be the configured declarative tree or a filename-ordered migration history.

Use this when

  • A pull request changes SQL and TypeScript together.
  • Database introspection cannot see the new schema yet.
  • You want runtime validators generated from the same source as migrations.
  • You want a typed, validated application boundary without adding an ORM schema layer.
  • You want generated application contracts without adding a provider-specific or ORM schema layer.

Do this

Generate types from the configured schema tree:
Override the source or output when needed:
For projects whose migration history is the reviewed schema source, generate from that history without introspection:
migrations: is also allowed as the generation before-state when it resolves to the configured migrationsDir; it is never a generation target, verify source, or drift source. supaschema sync refreshes configured TypeScript and Zod outputs as part of the full workflow. For the focused lane, run supaschema types after supaschema diff so schema, migration, and app types can be reviewed together. Use the generated schema-qualified owners as the application contract:
That covers the shape and validation responsibilities that teams often reach for an ORM-generated client to solve. Query execution can stay SQL-native through your PostgreSQL driver or platform client.

Verify

Commit generated outputs when your project reviews them:
Then run your app typecheck:

Types command

See type and Zod output flags.

Configuration

Set default output paths in config.

ORM-free apps

Use generated outputs as the application contract.

CI recipe

Keep generated files checked in CI.
Last modified on July 25, 2026