Backward compatibility is great. Your team needs to learn one thing, and it will work with minor modifications and get security updates until after you’ve retired.

SQLModel uses SQLAlchemy, which is database-agnostic. Not sure why this is a problem though. The benefit of the ORM is not being agnostic, it’s in managing schema changes under source control and automatic admin interface.

In my experience, the FastAPI-grab-bag always ends in regret, wishing we’d just used Django. It just works, and it has things you don’t even know you’ll need. If you get to the point where Django is the problem, you’re still glad you picked Django because you’ll be able to modify it to suit your needs. It brings convention without being enforced, and it’s pluggable. You can just not use forms (I never have), or templates (I like htpy), or not use the ORM, or use a different ORM. Django is just a request-response handler that’s already thought of everything you might need. If you want the FastAPI/pydantic approach you can use Django-ninja.

You can piece together your own car, but you’ll get a lot further if you just pick a Toyota Land Cruiser and drive it for a couple decades.

Being database-agnostic is not a problem per se. SQLAlchemy provides highly postgres-specific classes for the databases. The way Django implemented database-agnosticism is bad, because it's lowest-common-denominator which dragged all implementations down with it. They are pulling back from that now with a contrib.postgresql module but it's too late, there's a lot of old cruft now that forced design to be less-than-optimal on postgres.

I've done all four approaches on four different startups. Pure Django; DRF+React; FastAPI+React; Django-Ninja+React. The last one is the best, but from my experience, it does seem like SQLModel/FastAPI/React will be the route to go towards, but with some solid libraries to replace the still-useful batteries in Django: Authentication, Administration, Migration.