Comparing Django vs SQLAlchemy, Django's weakest point is its extremely static ORM syntax. The double underscore separation (e.g. user__group__name__icontains) for query parameters is likely my biggest pet peeve as it requires me to unroll unchecked strings together into a big garbled mess. I would have much appreciated being able to use more code-verbose query tools; the moment you have to go into building more dynamic user-defined query systems, Django's ORM just becomes a hindrance.

I also noticed the second part of the comment: Django does a lot of Python magic in the background through extensive use of reflection and class-level declarations, this hides away the abstractions (again) at the propose benefit of ease of use. And well, it is easy to use. For certain applications. I just personally found a lot of footguns trying to work with more advanced Postgres functionality (mainly around JSON) and it took a while to write my own abstractions atop the Django ORM to get to a comfortable level.

The inability to batch network calls in a single unit of work makes the ORM needlessly slow. That's also one of the main advantages to managing transactions/session yourself. It can save a huge number of round trips in a complex view.

The Django ORM itself is also slow at generating SQL. Recently I was bemused by a query, which took 500us to actually be generated. This wasn't doing anything particular wild, it just had a `select_related` call to an object that had about 50 fields (not great DB design, but beyond my control). The query actually took longer to build than it did to run.

That itself wouldn't be an issue if you could LRU cache the SQL query itself. But you can't, it's Django.