In Gladys, currently it is only possible to select:
The « aggregated » states are currently retained indefinitely.
The idea of this development would be to offer more fine-grained management of this area:
And to allow choosing a different retention period for aggregated states:
What do you think? Do the durations look good to you or should I add more?
I think that’s very good, it provides quite a few options; I admit I can’t really think of any particular case that would require even more duration options.
@guim31 what duration do you use?
3 months, without really ever having needed to go back any further.
Because the only thing I might want to consult/compare from one year to the next would be my electricity consumption, but I do that from the dedicated app for my solar panels which is very comprehensive.
Okay, but right now you’re keeping all the aggregated data indefinitely even though you only want it for 3 months ^^ So that’s not optimal 
Hence this project
I’m voting straight away because the database keeps growing, so I clean it myself from time to time to delete aggregated data.
Yes, exactly!
The pull request:
It’s true that more granular management will also limit the size of backups, because having only 3 months and unlimited was too restrictive — it’s good that these durations were added! 
So it’s retroactive?
If I first set it to unlimited, and then 1 year later set it to 1 month, will all the previous states be deleted as a result?
Yes, that same night at 4 a.m. it will be purged.
""in the evening" and "4 AM", that’s not supposed to make sense 
Thanks for the confirmation that, for now, aggregated data are kept indefinitely — I had forgotten.
A more or less silly question: I think you’ve already answered this, but topics sometimes evolve:
On that, I’ve been eyeing for a while a new file-based DB (like SQLite) but for time-series data; it’s called DuckDB and it’s becoming somewhat of a reference. I tested it and the space it uses compared to Gladys right now is pretty phenomenal (for time-series data, of course)
I was waiting for DuckDB to go stable to start work on it
As for InfluxDB for those who know it, why not have an integration, but for me it wouldn’t be a « recommended » way to do it but rather an integration for experts 
Indeed, you had already mentioned this project. I can’t wait for it to enter stable mode, because we’ll all be able to benefit from it:
I think the same, maybe even more, don’t get your hopes up about that aha
But that, yes definitely — that’s the whole point.
@lmilcent Here, if you want some hope, I ran a test with a 4.5GB DB of sensor states (varied data) imported into DuckDB.
We’re looking at a factor of 90, it’s pretty crazy 
(Well, it’s normal, it’s a time-series DB, it’s made for that)
Even knowing it’s designed for it, it’s impressive!
Currently 14 GB of database would yield 160 MB with a factor of 90. 
14GB is on disk, right? On the Gladys Plus side, compressed + encrypted, how big is it? Are your backups still working?
