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 queries .
In this benchmark, a small database is generated, and each test is executed 20 times under the following conditions:
|CPU||Intel(R) Core(TM) i7-2670QM CPU @ 2.20GHz|
|Linux distribution||Ubuntu 16.04 xenial|
Note that MySQL’s query cache is active during the benchmark.
- mysql is 1.1× slower then 4.5× faster
- postgresql is 1.1× slower then 10.3× faster
- sqlite is 1.1× slower then 5.8× faster
- filebased is 1.1× slower then 6.6× faster
- locmem is 1.0× slower then 7.4× faster
- memcached is 1.1× slower then 6.7× faster
- pylibmc is 1.1× slower then 6.8× faster
- redis is 1.1× slower then 6.7× faster
|||The ORM fetches way too much data if you don’t restrict it using