- we end up with many slightly different integrations, written by different people or even the same person at different points in time.
Ironically, our attempt at avoiding tech debt has caused us more tech debt.

One approach could be to build your data-models as a dedicated python module.

I mean different implementations of the integration between SQLAlchemy and Flask, in our applications. Not different implementations of the models, as each app has its own and that's expected.

I'm talking about the setting up of the DB, reading the URI from the config file, the script that calls MetaData.create_all() and then alembic.commands.stamp(), the creation of the session, the removal of the session when the request is done, the activation of foreign keys on SQLite, ways to check that the schema is up-to-date, etc etc. All this stuff that all of our DB-using apps need, and almost all of them have done differently.

Also you might want to check how deep SQLAlchemy is tied to your project (model, relationship, backrefs, sub_query, join, clause function, sesion, bulk_insert, etc) to see if this is such a big deal.

I think it's very very tied to the applications. You'll find SQLAlchemy-specific code in the model methods and in the views, but the app is also usually manipulating the model instances, calling their attributes on-demand, etc.

Do all the apps require relational db or not, or even at which percent?

I think a lot of them do, I'd say that non-DB using web apps are the exception (like webhook2fedmsg handlers)

I use since a while Aiohttp coupled with aiohttp-slqalchemy. those two work pretty well.
might want to look them up.

Interesting, I haven't tried those two. I don't suppose it lets you use SQLAlchemy's transparent attribute access in a non-blocking way? For example when calling Child.parents, SQLAlchemy will emit a query and populate the parents attribute with the result list, but that's a DB query and in the async world it should not block.

Thanks!

Aurélien