I have used VM for a while and for my use case it was way better than influxdb. VM process takes 70 to 100Mb memory on my system. Not bad, but not great. NanoTDB takes just about 10 to 20Mb, and that does include the dashboard. NanoTDB is much simpler in design and does have less features, but I think that's it's power. I didn't compare disk usage. NanoTDB is also very optimized for SD usage. You can tune it to be very resilient to shutdowns but less SD friendly, or you can tolerate missing some metrics and not write everything to the WAL file, and you can have anything in between.

New Release out. Docs updated. Check it out

Thanks for the reply and explanation. I added rollups to the readme file too

I expect queries to be mostly around a single or few sensors around date range. There is no index but the files for live readings are daily based, and reading single day file is extremely fast. Rollups are also supported and act like normal databases with a configurable period, monthly or yearly. And those can be queried pretty fast too

I already had that experience of some bad data and 85c degrees getting into my temperature sensor readings. BTW 85c just means it's invalid. So I do need to delete the bad data. The way it can be done now is to just export, filter and then import. I'll to resist the temptation to fix this

fellow DS18B20 user I see.

It's such a fucking stupid design quirk and so many drivers just don't compensate for it ;/

Sorry being late. Rollups were only pushed recently, as I thought about them for a long time until it finally clicked. This is main advantage over straight log files. Another things is that it is designed to be extremely efficient with SD cards. It uses WALS for keeping things safe, which is optional, and it writes very compressible data to the main database. My tests averaged 2-3 bytes per point, and the more data you have the more compression you get. So you can store many days of 10s data at less than few MBs.