This benchmark does not intend to be exhaustive nor fair to SQL. It shows how django-cachalot behaves on an unoptimised application. On an application using perfectly optimised SQL queries only, django-cachalot may not be useful. Unfortunately, most Django apps (including Django itself) use unoptimised queries. Of course, they often lack useful indexes (even though it only requires 20 characters per index…). But what you may not know is that the ORM currently generates totally unoptimised queries1.
Note that MySQL’s query cache is active during the benchmark.
The ORM fetches way too much data if you don’t restrict it using
.onlyand.defer. You can divide the execution time of most queries by 2-3 by specifying what you want to fetch. But specifying which data we want for each query is very long and unmaintainable. An automation using field usage statistics is possible and would drastically improve performance. Other performance issues occur with slicing. You can often optimise a sliced query using a subquery, likeYourModel.objects.filter(pk__in=YourModel.objects.filter(…)[10000:10050]).select_related(…)instead ofYourModel.objects.filter(…).select_related(…)[10000:10050]. I’ll maybe work on these issues one day.↩