3 ms·

We ingest a lot of time series (IoT) data and use Postgres for other data so Timescale works quite well for us. One thing Timescale treats as second class citiz

We ingest a lot of time series (IoT) data and use Postgres for other data so Timescale works quite well for us. One thing Timescale treats as second class citizen though is updates to existing data points which are 1-2 areas of magnitude slower than inserts. Granted this is also the case for all other TSDB solutions out there which are for obvious reasons optimized for inserts and reads aggregated along the time dimension. Still would be amazing if you could add to the already existing differentiation of allowing fast updates for cases like ours where we dont store events relating to a singular point in time but rather time-spans so new incoming data points might be "merged" into existing time-spans.

eternalban 7y ago
Same domain. I've come to the conclusion that these systems are dualistic in nature and the architecture needs to reflect that. I think the more general expression of this would be a time-series -> document-store pipeline. The concern then, if the time-series processing step requires domain data, is serving up fresh views of the evolving state in toto. That epsilon of temporal lag of 'current state' in the premier stage is a product issue. For some use cases it can be a very tight constraint, but I think quite a lot of others will be perfectly fine with snapshot isolation with generous requirement on freshness.