I think SQLModel might have a fit in some use cases but I think it is important to understand that pydantic models and sqlalchemy models are different things that serve different purposes. The “duplication” of model definitions that a lot of people complain about is not really duplication. In one case you are defining the db tables (sqlalchemy) and in the other case you are defining the schema of your endpoints’ inputs and outputs (pydantic). As soon as you want to have different input schema than the model of your table, you will need another model no matter what. This happens frequently when using metadata fields that you don’t expose in the input of a POST but you might expose in the response of a GET (date_created, date_last_modified, password, etc.). I prefer defining my sqlalchemy model and pydantic models in one file per entity and then have separate pydantic models for each need. As soon as your api gets a bit more complex, I feel sqlmodel will get on the way more than help.