InfluxDB can be improved by addressing issues such as performance drops, queries being more difficult to understand, and its high memory usage. InfluxDB is not suitable for relational databases like MySQL and Postgres, and these aspects can be improved. Sometimes, the setup is more challenging in InfluxDB. If it is not done properly, then I probably have to do it again.
One thing I appreciate about InfluxDB is its balance between performance and ease of use, especially with Flux making complex queries accessible. However, I do wish the documentation and community resources around Flux were more extensive and beginner-friendly. Additionally, InfluxDB handles time-series data well, but deeper native support for anomaly detection or machine learning integrations would be great. Overall, it is a strong platform, and these enhancements could really make it even more powerful for data-driven teams. InfluxDB is a strong platform, but there are a few areas where it could improve to better serve users and businesses. I would start with expanding and simplifying the documentation and community resources around its query language. It would help new users onboard faster and use the tool more effectively. Secondly, deeper native support for advanced analytics through machine learning integrations would add significant value by automating insights. The next thing I see is that enhancing the user experience around alerting, making it more intuitive and customizable, could really improve operational responsiveness. Lastly, better multi-tenant and role-based access control would really help organizations manage their security and collaboration more effectively. These improvements would make InfluxDB even more powerful and user-friendly for diverse teams. From a performance perspective, enhancing InfluxDB scalability for very high cardinality data sets would be beneficial as some use cases generate massive volumes of unique time-series. Improving the query optimization to reduce latency on complex queries would also help maintain responsiveness. On the integration side, expanding the native connectors to popular cloud platforms and data tools such as AWS services, BI platforms, and machine learning would be great. These improvements would make InfluxDB more adaptable and performant.
InfluxDB can be improved in several ways. The Flux query language needs to be learned, but if there were something similar to SQL or previous options, it would be much easier for users without imposing a learning curve. Additionally, clustering and high availability features are enterprise-only and definitely cost a lot of money, so scaling features come at a significant expense. The scaling feature is paid, and it should be free for those handling it.
If it gets a little bit more into the metric side, then it would really be great, similar to Prometheus. However, Grafana handles those things together, so I do not feel that improvement is needed. Rather than having two data sources, we could have just one data source with InfluxDB, and it could handle those things rather than having Prometheus and InfluxDB in place.
Although I didn't encounter any significant challenges, I think that if there was a NoSQL version of InfluxDB, that would also help because I have used the SQL version. I wish InfluxDB were also available in a NoSQL format similar to MongoDB, making it more user-friendly for those who are not database engineers. I would emphasize that documentation is very important because while I have found some documentation, the integration parts and technical hurdles that people might face, such as specific producers or consumers, have not been mentioned properly. If better documentation were available, allowing me to find everything, including specific port numbers and procedures, it would have been much easier, and I wouldn't have had to spend time researching how to integrate InfluxDB with my Kafka producers and consumers.
InfluxDB is good as it is, and I have not faced any issues so far, so I could not elaborate on how it can be improved.It could include automated backup and a monitoring solution for InfluxDB or a script developed by a REST API. I chose an 8 out of 10 because there is room for improvement, such as regarding backups and enhanced security through other types of authentication or encrypted data in TLS.
Solutions Engineer at a tech vendor with 51-200 employees
Real User
Top 10
Oct 3, 2025
I believe InfluxDB can be improved, but I'm not sure how; maybe some people can say more than me, but for myself, it is enough. I don't have any additional improvements to suggest regarding documentation, UI, or anything else that I wish was different; nothing comes to mind.
Student at a educational organization with 1,001-5,000 employees
Real User
Top 20
Sep 24, 2025
It's pretty much good regarding my use case, but I want to tell you that the interface of InfluxDB is so complex and should be made easier for non-technical people. With InfluxDB, I have to use Grafana, which provides good visualization, so I will tell you that mixing Grafana and InfluxDB would make visualization better in InfluxDB. Documentation is also required for InfluxDB, as I haven't got the documentation related to this, but there is a video on Udemy that helped me to use InfluxDB effectively.
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.
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 ( /products/flux-reviews ) language, I would like to see more development in this area and am unsure why FluxQL was deprecated.
Site Reliability Engineer(Observability) at Sapiens
Real User
Mar 11, 2024
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.
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.
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.
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.
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.
InfluxDB offers efficient time series data handling with fast writes, optimized storage, and seamless Grafana integration, making it ideal for high-volume applications like crypto trading and real-time monitoring. Its SQL-like query language and cloud-based options enhance user experience and system scalability.InfluxDB stands out with its ability to handle high-volume time series data efficiently, thanks to fast data writes and efficient compression. It is highly scalable, providing...
InfluxDB can be improved by addressing issues such as performance drops, queries being more difficult to understand, and its high memory usage. InfluxDB is not suitable for relational databases like MySQL and Postgres, and these aspects can be improved. Sometimes, the setup is more challenging in InfluxDB. If it is not done properly, then I probably have to do it again.
One thing I appreciate about InfluxDB is its balance between performance and ease of use, especially with Flux making complex queries accessible. However, I do wish the documentation and community resources around Flux were more extensive and beginner-friendly. Additionally, InfluxDB handles time-series data well, but deeper native support for anomaly detection or machine learning integrations would be great. Overall, it is a strong platform, and these enhancements could really make it even more powerful for data-driven teams. InfluxDB is a strong platform, but there are a few areas where it could improve to better serve users and businesses. I would start with expanding and simplifying the documentation and community resources around its query language. It would help new users onboard faster and use the tool more effectively. Secondly, deeper native support for advanced analytics through machine learning integrations would add significant value by automating insights. The next thing I see is that enhancing the user experience around alerting, making it more intuitive and customizable, could really improve operational responsiveness. Lastly, better multi-tenant and role-based access control would really help organizations manage their security and collaboration more effectively. These improvements would make InfluxDB even more powerful and user-friendly for diverse teams. From a performance perspective, enhancing InfluxDB scalability for very high cardinality data sets would be beneficial as some use cases generate massive volumes of unique time-series. Improving the query optimization to reduce latency on complex queries would also help maintain responsiveness. On the integration side, expanding the native connectors to popular cloud platforms and data tools such as AWS services, BI platforms, and machine learning would be great. These improvements would make InfluxDB more adaptable and performant.
InfluxDB can be improved in several ways. The Flux query language needs to be learned, but if there were something similar to SQL or previous options, it would be much easier for users without imposing a learning curve. Additionally, clustering and high availability features are enterprise-only and definitely cost a lot of money, so scaling features come at a significant expense. The scaling feature is paid, and it should be free for those handling it.
If it gets a little bit more into the metric side, then it would really be great, similar to Prometheus. However, Grafana handles those things together, so I do not feel that improvement is needed. Rather than having two data sources, we could have just one data source with InfluxDB, and it could handle those things rather than having Prometheus and InfluxDB in place.
Although I didn't encounter any significant challenges, I think that if there was a NoSQL version of InfluxDB, that would also help because I have used the SQL version. I wish InfluxDB were also available in a NoSQL format similar to MongoDB, making it more user-friendly for those who are not database engineers. I would emphasize that documentation is very important because while I have found some documentation, the integration parts and technical hurdles that people might face, such as specific producers or consumers, have not been mentioned properly. If better documentation were available, allowing me to find everything, including specific port numbers and procedures, it would have been much easier, and I wouldn't have had to spend time researching how to integrate InfluxDB with my Kafka producers and consumers.
InfluxDB is good as it is, and I have not faced any issues so far, so I could not elaborate on how it can be improved.It could include automated backup and a monitoring solution for InfluxDB or a script developed by a REST API. I chose an 8 out of 10 because there is room for improvement, such as regarding backups and enhanced security through other types of authentication or encrypted data in TLS.
I believe InfluxDB can be improved, but I'm not sure how; maybe some people can say more than me, but for myself, it is enough. I don't have any additional improvements to suggest regarding documentation, UI, or anything else that I wish was different; nothing comes to mind.
It's pretty much good regarding my use case, but I want to tell you that the interface of InfluxDB is so complex and should be made easier for non-technical people. With InfluxDB, I have to use Grafana, which provides good visualization, so I will tell you that mixing Grafana and InfluxDB would make visualization better in InfluxDB. Documentation is also required for InfluxDB, as I haven't got the documentation related to this, but there is a video on Udemy that helped me to use InfluxDB effectively.
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.
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 ( /products/flux-reviews ) language, I would like to see more development in this area and am unsure why FluxQL was deprecated.
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.
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.
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.
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.
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.
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.
The initial setup is a little bit complex. The error logging capability can be improved because the logs are not very informative.
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.