InfluxDB isn't as easy as it's sound to operate. Anything built on top of Postgres probably has year of knowledge to tune the db. but not much on InfluxDB. You

InfluxDB isn't as easy as it's sound to operate. Anything built on top of Postgres probably has year of knowledge to tune the db. but not much on InfluxDB. You are on your own. You cannot even easily upgrade InfluxDB, especially when you want to use some new feature such as enabling the TSI. When something is wrong, again, you're on the own. The question to InfluxDB HA isn't available as well. Yes, with all of that pain point, I'm still using InfluxDB. I even have to add in https://github.com/buger/goreplay https://github.com/buger/goreplay to support replaying traffic to other instance during upgrade. I have to write a tool to re-read old data and import into new instance instead of using their own import/restore. Many gotcha with InfluxDB, hard to explain to dev not using high cardinality for tag, or not using too many tag. For example, people get used to `tag` concept of `fluentd` and put stuff like user id, device id into tag... I want to log slow query time, now, I cannot use whole query as tag because of very high cardinality. However, I kept using InfluxDB. I want to support it so we have something better than Postgres. I'm sick of SQL query(personaly) and I would like for Flux to be successful. Similar to MongoDB, it's bad years ago but very good nowadays. I guess same thing will happen with InfluxDB. And indeed, they do improve over the year. Similar to how we use Ruby vs C. It's about productivity. And despite of above pain points, I always find a way to solve them eventually. And the tooling around InfluxDB is nice, especially Grafana.