async ORM czy na pewno?

Jest to wątek nawiązujący do tematu ORMy w Pythonie
Dodawanie async w starych ORMach, mam na myśli Django czy SQLAlchemy, nie jest łatwe, trwa długo. Nowe, okazuje się że zwykle są nakładką na SQLAlchemy.
W tutorialach o FastAPI zwykle używane jest SQLAlchemy. Wiec pytanie czy w ogóle jest sens budowania async ORMa?
Jedyny argument jaki zwykle słyszę za async ORM to, że przyspieszy działanie aplikacji i nie będzie blokować żądań więc zwiększy się wydajność aplikacji.
Ale jeśli jest to jedyny argument to problem wydajności aplikacji webowych już dawno został rozwiązany na różne sposoby.
Wchodząc w async, rozwiązując jeden problem, wprowadza się kilka innych problemów do rozwiązania, wiec czy ma to sens?
Może ORM powinien być synchroniczny tak jak do tej pory a tylko powinna być dodatkowa warstwa w aplikacji (wraper?), która umożliwia wysyłania do bazy zapytań asynchronicznie (coś co chyba było zrobione w AsgiMod) i to by wystarczyło.

Czy pisali tam o innych problemach niż "w normalnym języku awaitowanie syncowej funkcji jest noopem a w Pythonie rzuca TypeError że nie ma awaitable?". Faktycznie jest to upierdliwe i mogli by to poprawić bo w sytuacjach gdzie masz strategy pattern albo robisz synchroniczne funkcje asynchronicznymi, chociaż nie robią żadnego IO, albo robisz inspect.isawaitable co jest bardzo wolne.

ORM SQLAlchemy jest asyncowy, tylko używa greenletów zamiast Pythonowego async/await.

Wydajność eventloopów była bardzo fajna na Pythonie z wyłączonym GILem, gdzie cała maszynka patrzenia czy blokować zasoby między wątkami była czystym narzutem.

Niektóre widoki Misago dopytują o dane niezależne od siebie. Np. nie potrzebuję czekać na wynik zapytania wyciągającego profile użytkowników na liście tematów, kiedy pytam o informację który temat ma nieczytane posty. Teoretycznie w asyncu mogę zrobić:

new_threads, users = await gather(get_new_threads(request, threads), get_threads_users(request, threads))

I będzie to szybsze niż:

new_threads = get_new_threads(request, threads)
users = get_threads_users(request, threads)

Ale async w Django to ciężka przeprawa i ciągle wychodzą w tym nowe problemy.

Django tego próbowało i uderzyli w ścianę bo ORM nie jest w całości osobną warstwą, a miejscami przeplata się z cyklem życia żądania HTTP. Dlatego 6 lat później dalej ich async jest częściowy.