[tgv]

Yup. I've got a (legacy) postgresql database with time series: one timestamp plus measurement per row. And there's a useless third column too. It's awful, and sluggish.

For a newer project, where we basically use one object, I've chosen a NoSQL database. Get the object, edit it in the browser, put it back. Done. No need to update relations, ORMs or any of that. But: that won't fly for more complex projects.

So I agree: pick the right tool for the job.

[nhourcard]

Hi tgv, curious to hear why you picked NoSQL for your time-series use case?

[tgv]

It's not a choice that's guaranteed to suit your use case, but storing a time series as a large set of rows is not performant. Perhaps I should have mentioned that our time series data is "write once": we record and store it, but it doesn't get altered. And the time series are all sent to the browser, which does the displaying, filtering and analyzing, so there's no point in processing (our particular) time series in SQL, if that were even feasible. So, basically, because it is good enough, and better than the available alternatives.