InfluxDB Cloud Serverless

My main use case for InfluxDB  has been mostly for monitoring and analyzing the time-series data related to system metrics, and also tracking logs and API performance. In my current role, I use it to track trends and anomalies in the system's health, while I am also able to help identify performance issues early and support root-cause analysis.

In my current role, I have used InfluxDB  to monitor API responses, time, and server CPU usage in real-time. For example, I have set up continuous queries in InfluxDB to aggregate metrics such as average response time per minute and CPU load per server. This data feeds into the dashboards and then alerts the team when thresholds are breached, such as a spike in response time or CPU usage above eighty percent. When an alert triggers, I analyze the time-series data in InfluxDB to identify patterns or anomalies, which also helps pinpoint root causes quickly, such as a specific API endpoint. I have used this method for proactive monitoring, which reduces downtime and improves system reliability.

One scenario that really stands out is when we noticed intermittent spikes in API response time, which was affecting user experiences. Using InfluxDB, I was able to quickly analyze the time-series data, which correlated these spikes with specific backend processing runtime at the same time. This insight helped me identify a resource connection issue on certain servers. When we optimized the scheduling of those processes, it stabilized the response time and improved overall system reliability. I leverage InfluxDB as a core part of my monitoring workflow by continuously collecting and aggregating system metrics. This approach ensured that we maintain a balance between adding new features and keeping the system stable and performant.

The best InfluxDB features I think are its high-performance time-series storage and also a powerful query language and built-in support for down-sampling and continuous queries and real-time alerting, scalability and clustering options, and also the integrations with visualization tools. These are the features that help deliver a reliable, scalable solution.

I lean more on the query language because it gives me the most control and flexibility to analyze the data in-depth. While real-time alerting is more important for immediate notification, we have the ability to write complex queries with Flux , which allows me to explore data patterns and perform detailed root-cause analysis. The clustering is also valuable for scalability and high availability, but in my day-to-day work, the query language is the tool I use mostly to extract meaningful insights and drive decisions.

InfluxDB has had a significant positive impact on my organization. It has helped by enabling real-time visibility into system performance and user behavior. It helped our organization to quickly identify and resolve performance bottlenecks, which reduced downtime and improved user experience. This also has the ability to build custom dashboards and perform detailed time-series analysis, which has empowered both technical teams and business stakeholders to make data-driven decisions faster. This is how it has improved operational efficiency and allowed us to proactively address issues before they affect customers. Overall, InfluxDB has played a key role in enhancing system reliability and supporting our goal of delivering a seamless, high-quality product.

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.

I have been using InfluxDB for at least three to four years.

InfluxDB has proven to be very stable in our environment. We have used it to support mission-critical systems with continuous data ingestion and real-time analytics, and it is stable.

InfluxDB is highly scalable, which is one of its key strengths. It can handle large volumes of time-series data and with high ingestion rates, making it suitable for enterprise-scale deployments. This ensures consistent performance as data grows. Additionally, its retention policies and down-sampling features help manage stored data while maintaining query efficiency. In my experience, InfluxDB's scalability has allowed us to grow our monitoring and analytics capabilities without major re-architecture.

Customer support was really solid and responsive. In my experience, especially with enterprise deployments, having reliable support is crucial for maintaining uptime and resolving issues quickly. The InfluxDB support team was knowledgeable and helped us troubleshoot complex problems efficiently. They also provided guidance on best practices for scaling and optimizing performance. This support helped us avoid prolonged downtime and ensured smooth operation, which was important for our mission-critical systems. Overall, the support experience gave us confidence in using InfluxDB at scale.

Positive

Before InfluxDB, we used traditional relational databases and some open-source time-series tools which lacked the scalability and real-time capabilities. For example, we initially relied on PostgreSQL  for time-series data, but it struggled with high ingestion rates and complex queries on large data sets. We switched to InfluxDB because it is purpose-built for time-series data, offering better performance. This switch has really improved our ability to handle large volumes of metrics and logs efficiently, reduced query latency, and simplified our data architecture, which was critical for supporting real-time monitoring and analytics use cases.

We have seen a clear return on investment with InfluxDB. One specific metric I would like to share is related to our operational efficiency, where we have been automating real-time monitoring and alerting on system metrics using InfluxDB. We reduced manual incident detection time by about forty percent. This has allowed our team to proactively address issues faster, improving system uptime and reducing downtime cost. Additionally, automating these processes reduced the need for manual monitoring efforts, saving roughly twenty percent of the analytics team's time, which we redirected to higher-value tasks. These improvements translated into both cost savings and better service reliability, directly impacting business outcomes.

My experience with InfluxDB pricing and licensing has been generally positive, based on some considerations. Pricing is based on data volume, retention, and features, which really makes it scalable but requires careful planning to avoid unexpected costs. Cost management also involves monitoring data ingestion rates and retention policies closely to balance storage cost with business needs. The licensing terms are flexible enough to accommodate growth, but it is important to align with usage patterns to maximize ROI. Overall, the investment in InfluxDB has been justified by the reliability and insights it delivers, but it is important to have a clear cost strategy.

Before choosing InfluxDB, we evaluated several other time-series database options such as TimescaleDB and OpenTSDB. Prometheus was really strong for monitoring, but it lacked long-term storage and advanced querying capabilities we needed. TimescaleDB offered good SQL compatibility, but it did not scale as well for our high ingestion rates. OpenTSDB was considered, but it had more complex setups and maintenance overhead. InfluxDB stood out because of its balance of scalability, ease of use, rich query language, and strong community and enterprise support. This evaluation process helped us select the best fit for our specific business and technical requirements.

My advice for others looking into using InfluxDB would be to clearly define their time-series data use cases upfront to ensure that InfluxDB fits their needs, especially for high-frequency metrics or event data. Also, plan for scalability by evaluating whether the open-source or enterprise version fits their expected data volume and query load. Additionally, set up the proper monitoring and alerting on InfluxDB clusters to catch issues. Finally, engage with the community and support channels to stay updated on best practices and new features. From my experience, these steps helped ensure a smooth implementation and long-term success with InfluxDB.

InfluxDB is a strong choice for time-series, especially when you really need real-time insights and efficient storage of high-volume metrics. The flexibility of a query language such as Flux allows for powerful data analysis, but it also does require some learning investment. From a product perspective, balancing advanced features with ease of use is important. Overall, InfluxDB can deliver great value if you align it well with your business needs and user experiences, and if you plan for scalability and ongoing maintenance. This approach ensures the product stays useful and relevant over time, which is critical for any data platform. I would rate my overall experience with InfluxDB as an eight out of ten.

Positive

My main use case for InfluxDB  is that we are an IoT-based company with sensors and hardware, and we store sensor data into InfluxDB  for time series purposes.

A specific example of how I use InfluxDB with my sensor data involves a temperature sensor that requires readings every 30 seconds, such as temperature readings of 20 degrees or 40 degrees. We receive a sample every 30 seconds for temperature, and we also have energy data where we get a 30-second sample based on voltage and current measurements. We receive these kinds of data every 30 seconds, which amounts to a large volume of data per minute.

Regarding my main use case, we typically have sensor data, energy data, and HVAC data every 30 seconds. This is time series data, and it is substantial in volume. InfluxDB, being a time series database, is the only database suitable for storing this data. It is not feasible to use any other database for our purposes, so we chose InfluxDB.

we are the startups company but we have too much data we store for 30s interval , managing our own DB solution is very tough for us, we don't want to manage on premises DB, we choose to influxDB cloud DB. and for monitoring purpose we use free version with docker to publish application metrics.

The best features InfluxDB offers are related to the cloud version, which is very useful because there is no burden at all in maintaining an on-premises server. Everything is handled by InfluxDB, and we also have access to the support team. If we need optimization or help with queries, we ask for guidance and optimization from InfluxDB.

InfluxDB has positively impacted Energy Box by being the best choice for our needs. The cloud version and time series capabilities, along with a task scheduler, allow us to schedule tasks such as converting data from 30 seconds to one hour or one day. We can automate this process, so we do not need to worry about conversion code or scripting. We simply retrieve the data from InfluxDB.

How InfluxDB can be improved is relevant since for Energy Box, we face certain issues. We have customers worldwide, including the United States, United Kingdom, and Europe, but when we expanded to China two years ago, they indicated that they do not support the cloud version there. Our application is built on the cloud, which required us to create a separate application for Azure  China, which was painful for us. The second issue involves frequent version changes. For example, we started with version one, transitioned to version two, and I heard they are considering InfluxDB version three, reverting to earlier practices. InfluxDB should improve without completely changing its approach. Now we have to redo our work for InfluxDB version three.

Regarding needed improvements, the documentation is sufficient, but pricing presents a challenge. InfluxDB has standard pricing, which is acceptable for large companies. However, for startups in our position, they should provide special discounts so everyone can utilize it. The pricing should adapt as companies grow, which is a reasonable expectation.

I have been using InfluxDB at this company for the last four years with Energy Box.

Regarding features and performance, we sometimes face outages. One of the biggest outages occurred when AWS  experienced downtime, and we suffered considerably because InfluxDB cloud is hosted on AWS . We endured this for almost the entire day. Apart from that, we regularly encounter query issues. Additionally, we have another environment for Azure  China, where unfortunately, the InfluxDB team does not support the China region. They indicate that we can use the licenses, but they do not provide the cloud version there. This is a significant challenge for us as we must maintain the on-premises servers that we installed with InfluxDB. Performance is generally good, and with the help of the InfluxDB support team, we handle both Azure China and AWS day-to-day problems such as buffering data. For example, some devices being offline leads to missed data, which we address directly with the manager and technical support. They also helped us by establishing monitoring on Azure China since it is our on-premises server, managing and monitoring our database performance.

InfluxDB's stability is generally good, being stable 99 percent of the time.

Regarding scalability, since we use the cloud version, we do not need to scale at all.

The customer support is good, and they typically respond within 8 to 10 hours.

My experience with the cloud version is that for reporting purposes, we need to retrieve a lot of data to create reports on our platform. These reports can include substantial amounts of data, such as one year or one month of energy, sensor, and other device data. Obtaining that quantity of data directly from InfluxDB is quite challenging, and that is why we ask for help from the InfluxDB team to retrieve the data to avoid timeouts and those kinds of issues.

Before InfluxDB, we used MongoDB for storing time series data. We switched to InfluxDB due to its superior performance, as it was difficult to maintain data in MongoDB for our time series needs. We were also encouraged to make the switch due to better pricing, especially when we had a good budget.

I have seen a return on investment, as it is good for the company. It simplifies processes and reduces the need for additional employees. We invest in InfluxDB instead of spending time on workforce management.

I find the cloud version pricing of InfluxDB reasonable, and for the on-premises solution we use in our service, we need to purchase licenses. The price seems fair enough as per our organizational needs since we have a substantial amount of data that we are storing.

Before deciding on InfluxDB, we evaluated other options, including PostgreSQL  time series data, which is quite good and widely used. We opted for InfluxDB because we found it more valuable, requiring less effort with no maintenance on on-premises servers. We simply wanted the cloud version.

On a scale of 1 to 10, I would rate InfluxDB a 7.

I give it a 7 because the support and cloud version are available. I reduced the rating by 3 points due to some shortcomings. One shortcoming is that when we request too much data, it hangs considerably and does not provide results in one instance or experiences delays. However, 7 is an appropriate rating in terms of performance, pricing, support, and the cloud version.

InfluxDB is deployed as we use the InfluxDB cloud version, and in our application, we incorporate that cloud version. Our application is public, but it is specifically designated for customers.

We use two cloud providers for the InfluxDB cloud version, with 90 percent usage on AWS and the secondary being Azure China.

We do not purchase InfluxDB through the AWS Marketplace . Instead, we purchase it directly from InfluxDB and use it in our applications.

Additionally, I have further thoughts about InfluxDB. Sometimes, when we write too much data within a minute, the data count becomes excessive, reaching perhaps 100,000 or 500,000 data points, and InfluxDB gives a timeout exception, which we must handle in our application. Additionally, if the code is not adequate, we need to change it. These challenges also arise during production support. My overall rating for InfluxDB is 7 out of 10.

We are using InfluxDB  with Prometheus and Grafana  for monitoring the logs that are coming up as well as to create a powerful monitoring and analytics solution, encompassing data collection, metrics, and data storage.

Whenever the number of connections increases or we have our Elasticsearch where we have the logs, InfluxDB  gathers them and sends them. We created an analytics on it using the SRE people that are there.

Based on InfluxDB, we have great analytics produced by our SRE team, and with that, we have an alerting and monitoring system in place. Whenever there are a lot of things that are happening, such as the interaction going up and the number of logins increasing, then we get an alert that this is happening and we see that it's genuine or someone is trying to attempt something. This has helped us significantly.

We have our own metrics, as I mentioned from the SRE team, along with those logs. From there, we maintain the number of logins, the number of unique logins, and the number of logins at which period of time. These metrics are there so that we can even think about having an auto-scaler in place so that everything is auto-scaled.

InfluxDB's feature of data series over an extended period of time is valuable. We can watch logs even from the past three years and into a small range. For instance, in the past three years, from this moment till this moment, we can see how many logs are there and everything. We can watch it that way.

Firstly, the query language, as I mentioned, is based on SQL, so we can use SQL. Additionally, there is an open-source solution for it, which we can install on our system and work with those things directly. It is providing our own infrastructure-based solution, and it has a large community around it. That is the primary reason we chose it.

Firstly, it is open-source and has a great community. However, there could be much more improvement on the metric side that I have mentioned.

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.

I have been using InfluxDB for the past four years.

InfluxDB is pretty much stable.

In terms of scalability, it is highly scalable, as I mentioned that it has HA and backup plans available for it. It has handled a lot of data.

There is nothing as such that I can complain about. It is pretty much usable and very much intact.

Before InfluxDB, we were using Loki. However, we switched to InfluxDB because it has high availability, scalability is there, and error loggings sometimes perform better on that. For that reason, we moved from Loki and Prometheus to InfluxDB.

The first thing is that it will have a learning curve. You should have a POC or something that takes time because setting it up is somewhat difficult because it is a new thing for us. However, once it is set up, then you do not need to take care of it every time. It is auto-scalable, auto-healable, and all those things. That is the feature that you will always appreciate about InfluxDB. You must have a willingness to learn new things.

InfluxDB is set up in a database setting where we have authentication and it is pretty much easy to use with a query language similar to SQL. That is why it works for us.

Time saved is there, as I mentioned, because we have an analytics system from where we get alerting and monitoring. It is pretty much time-saving and things go right. However, not on the fewer employee side. We need employees because it has a learning curve, but it is definitely time-saving.

We are using an open-source solution, so there is no cost on that. However, on the server side, we needed a few things, such as CPU. We needed a good CPU and everything. This cost a bit for us.

We checked Apache Druid  and TimescaleDB.

Positive