Oui on est d’accord 
3.25 Go de backup !
C’est vrai que si on garde coché toute l’historisation cela fait conséquent, j’ai pour l’instant une dizaine de capteur et il prennent déjà 350Mo, après comment sont sauvegardées les données (à chaque changement de valeurs, selon un timer) ? Est-il
nécessaire de tout sauvegarder ou seulement selon des seuils (la pile par exemple c’est seulement si elle passe en dessous d’un seuil que cela peut être intéressant de connaitre la durée ou alors par palier 90% 85% etc) il y a des variations d’usages (température, humidité etc) et des variations de maintenance (batterie tension intensité etc) les deux couvrent pas les mêmes besoins donc la sauvegarde des données pourraient être différentes!
C’est ouf ces différences de poids, comment est-ce possible ?!
Ca serait long à expliquer mais ce qu’il faut retenir c’est que côté Gladys pour arriver à un requêtage assez rapide de données time-serie, on duplique la donnée plusieurs fois (les fameuses données agrégées), et on utilise des index qui sont eux aussi de la donnée dupliquée. Mis bout à bout, ça fait beaucoup de duplicata 
Dans une base de donnée timeserie, le format de donnée est différent et est optimisé pour des données temporelles, donc pas besoin de faire les pirouettes qu’on fait avec une DB relationelle. En plus de ça, une DB time-serie utilise des algos de compression pour stocker la donnée compressée et peut de-compresser à la volée à la lecture.
Après, tout ça a des tradeoffs, ces base de données timeseries ne sont bonnes qu’aux données temporelles, donc si un jour on implémente ça dans Gladys, ça sera uniquement la table « t_device_feature_state » qui partira dans cette DB, le reste restera dans SQLite (qui est ultra-robuste pour tout ce qui est relationnel)
3 « J'aime »
Cette fonctionnalité est disponible dans Gladys Assistant 4.31 ! 
Je ferme ce sujet pour libérer les votes, n’hésitez pas à créer un autre sujet en cas de bugs sur cette fonctionnalité