Well that sucks big time. Thankfully we switched from InfluxDB to QuestDB, and this news here just make me more convict that we made the right call.
We have a netflow analyzer with more than 350 b2b customers (regional ISPs) and we use to run InfluxDB as TSDB. A few things were bugging us though:
1) influxdb is being rewrited for the third time in less than 5 years;
2) v2 in hindsight was actually a downgrade from v1 in regards of performance (e.g: drop shard mechanism);
3) will they finally solve cardinality in v3? that was a major issue to be solved by v2...
I was just not confident sticking with influxDB. Thankfully another OSS project really surprised me in terms of performance and reliability, which is questdb.
Now we migrated more than 100 of our base and hopefully we will get all migrations done by the end of the year.
For my use case, there's one feature left to be add which is the inet type, in order to store IP addresses more efficiently.
We have a netflow analyzer with more than 350 b2b customers (regional ISPs) and we use to run InfluxDB as TSDB. A few things were bugging us though:
1) influxdb is being rewrited for the third time in less than 5 years;
2) v2 in hindsight was actually a downgrade from v1 in regards of performance (e.g: drop shard mechanism);
3) will they finally solve cardinality in v3? that was a major issue to be solved by v2...
I was just not confident sticking with influxDB. Thankfully another OSS project really surprised me in terms of performance and reliability, which is questdb.
Now we migrated more than 100 of our base and hopefully we will get all migrations done by the end of the year.
For my use case, there's one feature left to be add which is the inet type, in order to store IP addresses more efficiently.