However time taught me writing maintainable SQL with good migration story is way better. ORMs make porting queries to another project that needs to use the same database difficult.
It's less obvious what is really happening and the performance usually isn't as good as hand written SQL.
Hand written SQL also means fine grained control over prepared queries, access to vendor specific features (advisory locks, LISTEN/NOTIFY, triggers), materialised views etc.
You could argue these should be domain of DBA but in my opinion all devs should atleast know SQL at this level.
Wouldn't you have written a shared library through which both projects access the same database?
I know SQL pretty well (20+ years experience), but still use ORMs with nary a reason to hand-code any SQL any more. As a small-business-focused consultant using Microsoft technologies I do realise this puts me in a different bracket than others using larger-scale datasets and so forth, however for me using an ORM makes my life easier, makes me more productive, and with a little attention to detail doesn't result in performance issues for clients.
Are you arguing that that's a bug or a feature? Because literally every system I've worked with that's gone down this road has been a maintainability disaster, with the entire database schema treated as an API...