Fast enough. You get enough tools to optimize the queries. Keep in mind that Django is still a web framework. You can go nuts with Django and it starts to feel like maybe raw SQL would have been easier but I've rarely encountered this.

Fast to develop with? Yes.

Fast to run? Well.. no.. it's Python.

I personally care much more about development speed and time to market/customer than execution speed. It's good enough for 99% of cases.

The N+1 problem is solved in iommi (again, I am one of the authors) by simply:

1. keeping a log of queries per request with stack traces

2. at the end, checking if there are N+1 problems

3. print a big warning with example SQL and stack trace to the console

During dev if I miss a prefetch_related/select_related the console will start to print gigantic stack traces telling me where the problem is. I don't have these problems in production because I get alerted to them in dev.

These are not only solvable problems but EASILY solvable problems!

(Also, in iommi tables, most of the times it can automatically figure out and do the prefetch/select related for you, further diminishing the problem)

In EF line expression you can easily specify which navigation should be Eager loaded.

var customersWithOrderDetail = context.Customers.Include("Orders").ToList();

Would generate :

SELECT * FROM Customers JOIN Orders ON Customers.Id = Orders.CustomerId

Thankfully, not an issue as of today. EF Core has client-side evaluation disabled by default. It was an enormous footgun in EF so to bring that behavior back you have to explicitly opt into it.