Overview
SQLModel was created by Sebastián Ramírez, the author of FastAPI, and lives in the fastapi GitHub organisation. A class that inherits from SQLModel with table=True becomes a SQLAlchemy table, and the same class validates and serialises data like a Pydantic model, so you do not keep separate ORM and API schemas in sync.
Under the hood it is SQLAlchemy: sessions, engines and the select() query style are SQLAlchemy's, and any SQLAlchemy feature can be used when SQLModel's shortcuts are not enough. Migrations are done with Alembic, as with plain SQLAlchemy. The documentation is a step-by-step tutorial aimed at people new to SQL.
The project is still versioned 0.0.x (0.0.40 on 28 August 2026) and releases regularly, but there is no 1.0 and each release can change behaviour. Advanced SQLAlchemy features sometimes need workarounds, which the docs and issues discuss. SQLModel is best treated as a convenience layer: use it for straightforward models and APIs, and reach for plain SQLAlchemy constructs in the same project when you need something it does not wrap.
Pricing and plans
| Plan | Price | What you get |
|---|---|---|
| SQLModel | $0 | MIT licence |
What it does
- One model for DB and API
- A single annotated class is both the SQLAlchemy table and the Pydantic model used by FastAPI.
- Editor support
- Type annotations give autocompletion and inline errors when creating and querying models.
- SQLAlchemy underneath
- Engine, Session and select() are SQLAlchemy objects, so you can drop down to SQLAlchemy at any time.
- Relationships
- Relationship() attributes for one-to-many and many-to-many links between models.
- Tutorial-style docs
- Documentation teaches SQL and database basics alongside the library.
Strengths and limitations
Strengths
- Removes duplicate model definitions in FastAPI apps
- Gentle learning curve and beginner-friendly documentation
- Full SQLAlchemy power available when needed
- Maintained alongside FastAPI by the same organisation
Limitations
- Still pre-1.0 (0.0.x versions), so releases can change behaviour
- No migration tool of its own; you set up Alembic yourself
- Advanced SQLAlchemy patterns (complex inheritance, custom types) can be awkward through SQLModel's layer
- Mixing table models and API models in one class can leak database fields into APIs unless you define separate read/create models
Who it suits
Good for
- FastAPI apps with straightforward data models
- Beginners learning databases in Python
- Small to mid-sized APIs that want less boilerplate
Look elsewhere if
- Complex domain models that need SQLAlchemy's full mapping features directly
- Teams that require a stable 1.0 API
Alternatives to SQLModel
| Tool | From | Free option | Stages |
|---|---|---|---|
| Knex.js JavaScript SQL query builder | — | ||
| sqlc SQL-to-code compiler | — | ||
| SQLx Async Rust SQL toolkit | — | ||
| Active Record (Rails) Active Record ORM for Ruby on Rails | — | ||
| Eloquent ORM Active Record ORM for Laravel | — | ||
| Tortoise ORM Async Python ORM with a Django-like API | — |
Questions
Is SQLModel just SQLAlchemy?
It is a thin layer over SQLAlchemy and Pydantic; sessions, engines and queries are SQLAlchemy underneath.
How do I run migrations with SQLModel?
Use Alembic and point its target metadata at SQLModel.metadata.
Do I need FastAPI to use SQLModel?
No. It works in any Python code, though it was designed with FastAPI in mind.
Sources read for this page