Merci @Checconio pour la DB que tu m’as envoyé en privée, j’ai pu effectuer un petit audit de performance sur tes données et ça m’a beaucoup aidé, j’ai trouvé le souci ! 
Déjà, le souci était très clair, c’était hyper lent même sur ma machine de développement qui est assez puissante, je sais pas comment tu fais pour supporter ça c’était ultra lent ^^
Pour imager, je voyais ça:
Quasi 40 secondes pour afficher la page, c’est juste énorme ^^
J’ai passé Gladys localement en mode debug pour voir les requêtes SQL exécutés et je suis allé les jouer manuellement sur la DB, « en direct ».
6 secondes pour une requête qui renvoie rien, c’est beaucoup !
J’ai donc tiré la pelote, il y a 2 conditions sur cette query (WHERE device_feature_id = ? AND created_at >= ?), et ces deux attributs ont bien un index…
J’exécute EXPLAIN QUERY PLAN pour comprendre ce que fait SQLite, et je comprends.
SQLite pouvait utiliser l’index sur device_feature_id pour aller chercher tous les états de cette fonctionnalité, mais ensuite il faisait un scan sequentiel pour aller filtrer par date: l’index sur date n’était pas utilisé.
La solution est tout simple, il suffit d’ajouter un index qui couvre les 2 attributs utilisés lors de la requête.
J’ai donc rajouté 2 index sur device_feature_state et t_device_feature_state_aggregate couvrant les attributs utilisés lors des requêtes du tableau de bord.
await queryInterface.addIndex('t_device_feature_state', ['device_feature_id', 'created_at']);
await queryInterface.addIndex('t_device_feature_state_aggregate', ['device_feature_id', 'type', 'created_at']);
Et là: bam! Cette même requête passe de 6 secondes à… 5ms !! 
Sur la totalité de la page, on passe de 40 secondes à… 100 ms sur ma machine !
Je te l’avais dis, c’était pas du à SQlite, on aurait eu le même soucis sur MySQL 
J’ai fais une PR qui corrige le souci, ça partira dans la prochaine version de Gladys:
@Terdious @lmilcent ça va vous intéresser vous qui avez beaucoup de data !