We have tried to upgrade from gino to sqlalchemy 1.4, but at least as of now (April 2021), it is not worth it.

The only benefit of sqlalchemy that gino lacked was many to many relationship management to us, but migration process have shown that sqlalchemy has more issues.

It is possible to migrate, but we would have to rewrite half of our system, introduce dozens of breaking changes and bugs for basically almost no benefit.

Plus, sqlalchemy 1.4 is stable, but not yet as mature as previous versions. Also, async support is in beta. Maybe when it is stable too, we will reconsider the migration.

We won't be migrating to sqlalchemy, but if someone provides a good PR which does the migration without breaking everything and if it works great and is easy to maintain, then we will switch.

The problems we have met with when switching which need to be solved efficiently:

• Database session management. Where to put it? Gino had a global Gino object which managed everything correctly. We tried two ways, one from https://github.com/mfreeborn/fastapi-sqlalchemy, but adapted to async, and another is implemented like in the coming example to fastapi, via dependency: Add asynchronous sqlalchemy example fastapi/fastapi#2331
  First way had problems with concurrency (another operation is in progress), another one seems to be fine, only that we must move session everywhere we need it and can't easily access it like before (also a question of how to use the dependency in worker tasks for example, outside of the fastapi context, is still there)
• Relationship management. Main issue is there. Pre-loading a one to many relation is good to have, as we often need it, but in case of many-to-many relation not really. Performance implications are there, but that's not the most important thing. When in frontend and outside backend, we just use related objects id's. Because adding in full object and passing them via API is impossible as the requester can't know the full object sometimes. And in general it is not comfortable to operate with objects instead of ids. When in backend, sometimes we access those ids and fetch exact objects. But in most cases only a list of ids is required. If we still keep our add_related functions it will work, but then what's the point of using sqlalchemy if it doesn't help with the only gino's problem we had? Plus we would still have to control precisely what to return.

Those two problems are essential, which stopped us from continuing. There are definitely more problems which we would have discovered, like the connection management and it's garbage collection (I saw warnings in console), plus other sqlalchemy bugs which might be there.

If someone still needs it, I left my unfinished work at sqlalchemy-1.4 branch