История изменений

как часто тебе нужна именно асинхронная orm

Если пилишь бложик, нафиг не надо. Если пилишь микросервис, где приличное число запросов в секунду и много взаимодействия с другими сервисами по сети, то почему бы и нет - лишним бы не было.

Ok, чем тебе, допустим, sql-alchemy не нравится или django-orm?

Насчет sql-alchemy ничего не скажу (с ней, можно сказать, не работал), но django-orm не нравится, например, тем, что ее без Django юзать нельзя. А юзать Django в 2020-м, когда во фронте господствуют вуи и реакты вообще бессмысленно (правда я-таки юзаю), потому что большая часть функциональности Джанги все равно использоваться по итогу не будет. К тому же даже если вытащить как-то ORM из Django, ума не приложу, как ее в юнит-тестах можно замокать, чтобы запросы в базу не ходили (например, для тестирования сервисного слоя)?

Что касается миграций, то их вообще можно юзать хоть сторонним инструментом. Тем более, что этот процесс неплохо было бы контролировать и видеть запросы глазами, а не через объекты ORM. А то на огромную таблицу в проде поедет миграция создания индекса без CONCURRENTLY - и приехали.

как часто тебе нужна именно асинхронная orm

Если пилишь бложик, нафиг не надо. Если пилишь микросервис, где приличное число запросов в секунду и много взаимодействия с другими сервисами по сети, то почему бы и нет - лишним бы не было.

Ok, чем тебе, допустим, sql-alchemy не нравится или django-orm?

Насчет sql-alchemy ничего не скажу (с ней, можно сказать, не работал), но django-orm не нравится, например, тем, что ее без Django юзать нельзя. А юзать Django в 2020-м, когда во фронте господствуют вуи и реакты вообще бессмысленно (правда я-таки юзаю), потому что большая часть функциональности Джанги все равно использоваться по итогу не будет. К тому же даже если вытащить как-то ORM из Django, ума не приложу, как ее в юнит-тестах можно замокать, чтобы запросы в базу не ходили (например, для тестирования сервисного слоя)?