Now give me a plot with the average of all sensors of model=A in region=B, grouped by customer, for the past 3 months, downsampled to 500 points. Assuming 1 sensor reading per minute.
I have no doubt sql can do it without too much trouble, but for a time series this is really an instant operation, even on a small server.
A time series will first find the relevant series and then simply for-loop through all the data. It takes just a handful of milliseconds.
Sql will need to join with other tables, traverse index, load wider columns. And you better have set the correct index first, in your case you also spent extra effort on partitioning tables. Likely you are also using a beefy server.
Adding to your comment, from my perspective (exploration geophysics)
> and just contains tons of data coming in from sensors.
it's also desired to, on the fly, deal with missing sensor data, clearly bad sensor data, identify and smooth spikes in data (weird glitch or actual transient spike of interest), apply a variety of running filters; centred average is basic, parameterised Savitzky–Golay filters provide "beefed up" better than running average handling .. and there are more.
It's not just better access to sequential data that makes a dedicated time series engine desirable, it's the suite of time (and geo spatial) series operations that close the deal.
I have no doubt sql can do it without too much trouble, but for a time series this is really an instant operation, even on a small server.
A time series will first find the relevant series and then simply for-loop through all the data. It takes just a handful of milliseconds.
Sql will need to join with other tables, traverse index, load wider columns. And you better have set the correct index first, in your case you also spent extra effort on partitioning tables. Likely you are also using a beefy server.