It's just de/serialisation. IMO if you feel totally dependent on a single library for doing this for you then you're doing too much in that layer. This should be a tiny thin layer right at the edge of your application just for getting data in/out. I've seen people build almost their entire application in Pydantic classes. You're doing it wrong.
I don't know why people like this pattern of "fat" classes with built in de/serialisation/persistence logic at all. It makes so much more sense to have that at the edge and build entities and/or value objects directly. Using stuff like Pydantic or Django ORM you either end up completely coupling domain logic to serialisation logic, or you end up manually writing data mappers to/from your domain when you could have just used, for example, cattrs or SQLAlchemy. I guess it's the "easy vs simple" thing.
would you say the same of SQLModel? Which I think is an ideal solution (theoretically), better than SQLAlchemy
SQLModel is even worse as it couples everything together. It's only good for basically building a JSON interface on top of a database. I guess it could be useful for a very basic web app. But the moment you start needing logic on the backend beyond basic read/write permissions you're screwed. At that point you either rewrite or proceed to build a big ball of mud.
In my experience backends never stay simple enough for SQLModel so you might as well decouple from the get go. If it's literally just copy/paste between SQLAlchemy models and Pydantic just do the copy/pasting. Get an LLM to do it if you have to. It will be worth it in the long run. You'll want to change your db schema without breaking your API.