[silvester23]

> If you ever write bad data to a measurement in InfluxDB, there is no way to change it

Correct me if I'm wrong, but I'm fairly certain you can just write data with the same timestamp again and it gets updated. Deleting is also easily possible.

[iliekcomputers]

ListenBrainz dev here. We wanted stuff like the ability to do stuff like "DELETE FROM measurement where field = blah" and that support didn't exist last time we looked. [0]

Another thing that's not mentioned in the post but was a pain point for us was that it's not easy to query for fields with "null" values [1].

I figure a lot of our pain might be because we're not as good at Influx as we are at PostgreSQL. We've been running MusicBrainz[2] for ~18 years on PostgreSQL, that knowledge will hopefully transfer over a little with Timescale.

[0]: https://github.com/influxdata/influxdb/issues/3210

[1]: https://github.com/influxdata/docs.influxdata.com/issues/717

[2]: https://musicbrainz.org

[silvester23]

True, deleting by value does not seem to be possible. I can see how that would be painful if it's necessary for your use case.

[sgt]

You can't for example delete data from a time period to another, to the best of my knowledge.

[sciurus]

This is actually pretty straightforward. For example,

`DELETE FROM "foo" WHERE time >= now() - 2d AND time < now() - 1d`

[sgt]

Ok, we had an issue deleting data from a series. The delete just hung and never completed. I assumed this was not really possible on Influx. Perhaps this is an edge case.

[samhld]

(Solution architect at InfluxData here) Out of curiosity...what was the need for this DELETE? Deleting (not dropping) being somewhat of a "second class citizen" was a design choice to make room for more pressing time series needs. In my experience, `DELETE`ing is rarely necessary.

[silvester23]

We work a lot with forecast data and sometimes mistakes happen and a forecast gets written to the wrong time series or for the wrong period. In these cases we do not want to drop the complete time series but only delete the erroneous parts.

While it is indeed a rare occurence, it is also very slow.

[majkinetor]

I often use metrics for giving reports via Grafana. They are usually 99% correct which is good enough for many cases. The benefit of doing so is that you already need and have nice dashboard for devs to follow what is going on with the system real time, and its just grafana account distant from customer. So we do this on several big gov systems. Sometimes customers complain that there is a slight difference between real state and what metrics show but its not a big deal and rarelly happens (when you have millions of things, is it really important to know 100% precise value in majority of contexts?)

Recently my colegue was testing some script and added some huge numbers on metric that is used for one of those reports. We had to delete those tests as customer complained that now his total invoice number jumped to trillions.

[sgt]

It was actually a bunch of data that was inserted coming from an IoT device that was invalid. So just deleting that time period and limiting to a tag would have been sufficient.