It is challenging to get long-running backups while running InfluxDB in a Microsoft Azure Kubernetes cluster. Replicating data for on-prem development and testing is difficult. Having a SQL abstraction in InfluxDB could be beneficial, making it more accessible for teams that prefer querying with SQL-style syntax.

View full review »

One area for improvement is the querying language. InfluxDB deprecated FluxQL, which was intuitive since developers are already familiar with standard querying. Though we can adapt to the Flux language, I would like to see more development in this area and am unsure why FluxQL was deprecated. View full review »

InfluxDB is generally stable, but we've encountered issues with the configuration file in our ticket stack. For instance, a mistake in one of the metrics out of a hundred KPIs can disrupt data collection for all KPIs. This happens because the agent stops working if there's an issue with any configuration part. To address this, it is essential to ensure that all configurations are part of the agent's EXE file when provided. This makes it easier to package the agent for server installation and ensures all KPIs are available from the server. Additionally, the agent cannot encrypt and decrypt passwords for authentication, which can be problematic when monitoring URLs or requiring authentication tokens. This requires additional scripting and can prolong service restart times.

View full review »

There were concerns about data loss due to infrastructure limitations. We couldn't back up data locally if we were using the InfluxDB cloud, which was a major drawback. So, InfluxDB could improve its data backup capabilities.

Having a backup option would allow us to save data and avoid relying solely on cloud infrastructure. We've experienced data loss incidents in the past, so backup is crucial. I've tried both on-premises and cloud-based deployments, and each has its limitations.

View full review »

Influx has TICK Stack, which contains multiple services and multiple products that work together. InfluxDB is just a time series database, and it works really well. I haven't yet had the time to look into the new stack based on Influx 2.0, but currently, as a time series database, InfluxDB is working the way it is supposed to work. 

In terms of features that I would like to see or have, in the community version, some features are not available. I would like to have clustering and authentication in the community version. 

I would also like to have high availability features, such as replication, active-active, etc. If they can put an extra plugin or service on top of it, it would be something interesting. I am not sure if they have high availability to make it data center-aware for clustering. For example, I am not sure whether you can have it at different locations with big clusters that are location-aware. Even in their documentation or presentation, they talk too little about high availability and extended clusters with different locations. They might already have it in the newer versions. We have Influx 1.8 in our production in the stage and internal workloads environments. 

The other products in their ecosystem, such as Chronograf, can be improved. Chronograf is a dashboarding or visualization layer product, and that, for sure, can be improved.

View full review »

The solution's UI can be more user-friendly.

I would like to have better more detailed documentation on how to integrate the solution with other tools.

View full review »

InfluxDB cannot be used for high-cardinality data. It's also difficult and time-consuming to write queries, and there are some issues with bulk API. 

View full review »

InfluxDB can improve by including new metrics on other technologies. They had some changes recently to pool data from endpoints but the functionality is not good enough in the industry.

In the next release, it would be beneficial if they added more query language compatibility it is critical for us.

View full review »

The initial setup is a little bit complex.

The error logging capability can be improved because the logs are not very informative.

View full review »

The solution doesn't have much of a user interface.

The integration of Chronograf and Capacitor is not so good. They could work to make it better.

View full review »