Long-standing backlog issue is migration to SQLAlchemy. Let's discuss it :-)

• I'm not sure if it is still a gain for us. Most of the SQL code was converted to *Processor which is pretty sufficient now. What is the real pain are the schema migrations which would benefit from either core SQLA migrate or (maybe better) alembic.
• are there any better-suited db/orm libraries these days? Django db/ORM is quite complex and I wouldn't pull it in, peewee is maybe not that matured for potential deeper psql magic?

Pros:

• migrations
• a bit easier input handling/sanitizing
• lower barrier for new devs?

Cons:

• another dependency
• code migration work
• crucial code which is not under our control (security)

If we choose to use it, we still have some options:

• convert *Processor to use SQLA behind the scenes (preferred by me)
• drop Processor and rewrite its uses to SQLA directly (error-prone)
• new code could/should use SQLA directly or is is the Processor approach better even for the future? I think SQLA would be better here - we can rewrite even the rest of SQL which doesn't fit into Processor design with SQLA.
• do we want to use SQLA ORM? I'm not inclined here as we don't use OOA for db records now and we're passing dicts everywhere. Maybe it is some separate issue for the future when db layer will be fully functional under SQLA.