This may not apply in your case, but since I'm familiar with a similar usage, I wanted to give you a heads-up. If your config will ever involve multiple nodes, beware that startup time for new nodes will be quite extended if you have a lot of time-series data like sensor readings. You might want to consider a split system where the document-like things are stored on xtdb with foreign keys to a dedicated time-series system for that data. E.g. all the information about the sensor would live in xtdb except for the sensor readings.

That's helpful! Actually, my current primary use case is more like every day. But I dabble in esp32 stuff so those updates are much more frequent and this is good to know for those projects.

It seems like many of the xtdb examples are about finding out what a value was at a given point rather than time series.

@U01GXCWSRMW That chimes with my experience too. That said for this case there's https://v1-docs.xtdb.com/language-reference/datalog-queries/#history-api which allows you to get all the times an entity changed over valid time. Here's an example: https://gist.github.com/Akeboshiwind/87ed84c715576ec50227ca260072b302

I'll also note that v2 has a much better https://docs.xtdb.com/reference/main/xtql/queries.html#temporal-filter. Currently with v1 you wouldn't be able to (in the query) do any filters or transformations on the documents. But if you're just wanting to graph a series of numbers that's probably not needed 🤷