But we are at the point where async python has really taken off, as well as where the performance gains are just impossible to ignore except for apps thats are either dead-simple or that are super CPU-bound. And FastAPI is unquestionably leading the pack with regards to async frameworks, so it makes sense to target that. (Also, yes, he's the creator.)
(Additionally, FastAPI is using Starlette under-the-hood, which is built on ASGI, part of the point of which is to standardize async servers and frameworks to allow for wide compatibility. Anything that works on Starlette or any ASGI framework will work with FastAPI, and vice versa unless the component is tightly coupled to FastAPI-specific code.)
But I agree largely that Flask is now a thing of the past. If you want to very quickly bring a small API server or a simple view page up then it's fine. For almost anything more complex, it's a huge pain. The ecosystem is extremely fragmented and lots of vital plugins for core systems like caching, auth and such aren't maintained anymore. For someone starting a new project, even if it's a very small web server I'd prefer FastAPI
Because he is the author of FastAPI
But as @tomnipotent says below, a SQLModel is also a Pydantic model, so, you can use the same model to do automatic API data validation, serialization, documentation, filtering... and now, also define the database.
There's no more integration, apart from the fact that I built it to do just that, and I made sure everything works just right with FastAPI.
But for any other framework that doesn't have automatic data validation, documentation, serialization, etc. (and you are just doing that by hand) it's an even simpler problem, so SQLModel will work just right, as any other ORM.
FastAPI is basically the (async) 2021 version of Flask just built on Starlette instead.
If you have used Flask before, the learning curve will be pretty low, and the documentation is great.
But of course people have been using SQLAlchemy and Flask together for ages so I don't see any reason you couldn't use this with Flask instead if you prefer. That said, I bet you'll be able to whip up the MVP even faster using FastAPI.
I do not have any affiliation with the project other than being a happy user today.
A SQLModel is also a Pydantic model. FastAPI uses Pydantic.
Just wanted to mention that you emphasize "optimized for FastAPI" but it looks like it does nothing to do with FastAPI.
Do you have any reason to narrow down the scope to FastAPI when other frameworks like Flask are still more widely used?
Specifically mentioning only one framework causes loosing interest of people who use other frameworks.