My main use case for InfluxDB is for server management metrics, Kubernetes monitoring, and application performance monitoring due to the time series data involved. We have InfluxDB integrated with Grafana, so whenever we have an application running, we send server metrics, CPU, memory, network, and any other metrics to InfluxDB. From there, we benefit from millions of writes per second and Prometheus-like workloads with observability pipelines, allowing us to create proper monitoring pipelines for our SRE dashboard.
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.
My main use case for InfluxDB involved working on a LEO satellite KPI monitoring application, where I gathered latency, throughput, packet loss, jitter, and various types of network data for several probes. We had around a lakh of probes, and I needed to gather information from all these probes and store it in a database. I chose InfluxDB because it is a highly reliable and purpose-built database used for storing and analyzing real-time network and performance metrics. It served as the core data store for latency, jitter, packet loss, and throughput KPIs I collected using tools such as iperf3, MTR, and custom Python scripts. Its strongest advantage was its ability to ingest high-frequency metric data with JSON-based metric payloads generated by automation scripts written efficiently using the Influx line protocol, enabling near real-time visibility through performance bottlenecks. Regarding further integration of InfluxDB with my tools and scripts, I used Telegraf and Chronograf as well since InfluxDB was the database where I ingested all the data, including throughput, latency, packet loss, and jitter. Although I don't exactly remember all the network data types involved, the main problem was the amount of data. Although InfluxDB is a highly scalable database, the main challenge with InfluxDB, which is common with all databases, was handling very high throughput systems and high throughput message flow. Thus, I had to use Kafka as well, which generated Kafka topics and resolved the high throughput problem.
My main use case for InfluxDB is working on a monitoring system for Cisco products, mostly Cisco switches and routers, as a time series database.A specific example of how I use InfluxDB in my monitoring system is that we gather the metrics from the devices with Prometheus, and then we use InfluxDB to store those data, then consume all the data in Grafana. I connect everything together by running it in a Docker Compose.
My main use case for InfluxDB involves gathering metric data from our storage clusters and putting them into Grafana dashboards, so InfluxDB is the data source for Grafana. I collect and display metrics in Grafana such as throughputs, IOPS, latencies, quota consumptions, network and cart errors. Regarding my main use case, there are no particular challenges; we run our scripts every five minutes, so we gather data from our clusters every five minutes and keep more than six months.
Student at a educational organization with 1,001-5,000 employees
Real User
Top 20
Sep 24, 2025
I have been using InfluxDB for one year for my project, Greenhouse Management using Embedded System, to represent the sensor data on a web dashboard. I have used InfluxDB for storing the data and representing it on a web dashboard for my greenhouse project, and that is the only thing I have used InfluxDB for.
InfluxDB is the main component in our large enterprise-scale streaming data application for maritime vessels. We collect position data from vessels around the coast once per second, put it on a Kafka stream, and feed those positions into InfluxDB continuously. This has been working flawlessly since 2018. We have seven years of time-series data for all the vessels that my company operates, roughly 130 to 140 vessels. Every move they make is being tracked and stored in InfluxDB.
We are developing a trading agent that uses multiple machine learning models to adapt to the crypto market in real time. InfluxDB ( /products/influxdb-reviews ) is used to collect data on crypto coin prices from exchanges like Binance and Bybit. Our use case requires low latency and the ability to query data effectively. We use InfluxDB ( /products/influxdb-reviews ) on a DigitalOcean ( /products/digitalocean-reviews ) infrastructure in a containerized environment with Docker ( /products/docker-37146-reviews ).
I use the solution to store and manage data from various sensors in a production environment. I have developed a system where data from these sensors is communicated through an OPC UA receiver and stored in InfluxDB. It handles serial data from sensors effectively and integrates well with Grafana for visualization.
InfluxDB is a database where you can insert data. However, it would be best if you had different components for alerting, data sending, and visualization. You need to install tools to collect data from servers. It must be installed on Windows or Linux servers. During installation, ensure that the configuration file is correct to prevent issues. Once data is collected, it can be sent to InfluxDB. For visualization, you can use open-source tools like Grafana.
Initially, we used Prometheus and Grafana for alerts. But, it wasn't feasible to handle logs and other types of databases. We then switched to InfluxDB due to its user interface, which allowed us to customize alerts, data visualization, and filtering for monitoring purposes.
Our usage of Influx is very specific. We use it for our casino stack and applications. We use it for monitoring, logging, and metrics and trend analysis for player wagering. It is for casino data. We correlate all that data and generate reports for data warehousing. So, we use it massively in our stack for the casino for a lot of things. We haven't yet migrated to Influx 2.0. We are still using Influx 1.8 because we have multiple workloads in production. It is going to take some time, and we need to ensure that the latest one is stable and the framework also brings a lot of different languages. We use it on-premise and in the cloud. We have both. It is a private cloud on AWS.
Software Engineer at a tech services company with 5,001-10,000 employees
Real User
Nov 22, 2020
We don't use a managed service. Rather, we manage it ourselves. We have deployed it and right now, we are using it for log aggregation with a two-week retention policy.
InfluxDB is open-source software that helps developers and enterprises alike to collect, store, process, and visualize time series data and to build next-generation applications. InfluxDB provides monitoring and insight on IoT, application, system, container, and infrastructure quickly and easily without complexities or compromises in scale, speed, or productivity.
InfluxDB has become a popular insight system for unified metrics and events enabling the most demanding SLAs. InfluxDB is used in...
My main use case for InfluxDB is for server management metrics, Kubernetes monitoring, and application performance monitoring due to the time series data involved. We have InfluxDB integrated with Grafana, so whenever we have an application running, we send server metrics, CPU, memory, network, and any other metrics to InfluxDB. From there, we benefit from millions of writes per second and Prometheus-like workloads with observability pipelines, allowing us to create proper monitoring pipelines for our SRE dashboard.
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.
My main use case for InfluxDB involved working on a LEO satellite KPI monitoring application, where I gathered latency, throughput, packet loss, jitter, and various types of network data for several probes. We had around a lakh of probes, and I needed to gather information from all these probes and store it in a database. I chose InfluxDB because it is a highly reliable and purpose-built database used for storing and analyzing real-time network and performance metrics. It served as the core data store for latency, jitter, packet loss, and throughput KPIs I collected using tools such as iperf3, MTR, and custom Python scripts. Its strongest advantage was its ability to ingest high-frequency metric data with JSON-based metric payloads generated by automation scripts written efficiently using the Influx line protocol, enabling near real-time visibility through performance bottlenecks. Regarding further integration of InfluxDB with my tools and scripts, I used Telegraf and Chronograf as well since InfluxDB was the database where I ingested all the data, including throughput, latency, packet loss, and jitter. Although I don't exactly remember all the network data types involved, the main problem was the amount of data. Although InfluxDB is a highly scalable database, the main challenge with InfluxDB, which is common with all databases, was handling very high throughput systems and high throughput message flow. Thus, I had to use Kafka as well, which generated Kafka topics and resolved the high throughput problem.
My main use case for InfluxDB is working on a monitoring system for Cisco products, mostly Cisco switches and routers, as a time series database.A specific example of how I use InfluxDB in my monitoring system is that we gather the metrics from the devices with Prometheus, and then we use InfluxDB to store those data, then consume all the data in Grafana. I connect everything together by running it in a Docker Compose.
My main use case for InfluxDB involves gathering metric data from our storage clusters and putting them into Grafana dashboards, so InfluxDB is the data source for Grafana. I collect and display metrics in Grafana such as throughputs, IOPS, latencies, quota consumptions, network and cart errors. Regarding my main use case, there are no particular challenges; we run our scripts every five minutes, so we gather data from our clusters every five minutes and keep more than six months.
I have been using InfluxDB for one year for my project, Greenhouse Management using Embedded System, to represent the sensor data on a web dashboard. I have used InfluxDB for storing the data and representing it on a web dashboard for my greenhouse project, and that is the only thing I have used InfluxDB for.
InfluxDB is the main component in our large enterprise-scale streaming data application for maritime vessels. We collect position data from vessels around the coast once per second, put it on a Kafka stream, and feed those positions into InfluxDB continuously. This has been working flawlessly since 2018. We have seven years of time-series data for all the vessels that my company operates, roughly 130 to 140 vessels. Every move they make is being tracked and stored in InfluxDB.
We are developing a trading agent that uses multiple machine learning models to adapt to the crypto market in real time. InfluxDB ( /products/influxdb-reviews ) is used to collect data on crypto coin prices from exchanges like Binance and Bybit. Our use case requires low latency and the ability to query data effectively. We use InfluxDB ( /products/influxdb-reviews ) on a DigitalOcean ( /products/digitalocean-reviews ) infrastructure in a containerized environment with Docker ( /products/docker-37146-reviews ).
I use the solution to store and manage data from various sensors in a production environment. I have developed a system where data from these sensors is communicated through an OPC UA receiver and stored in InfluxDB. It handles serial data from sensors effectively and integrates well with Grafana for visualization.
InfluxDB is a database where you can insert data. However, it would be best if you had different components for alerting, data sending, and visualization. You need to install tools to collect data from servers. It must be installed on Windows or Linux servers. During installation, ensure that the configuration file is correct to prevent issues. Once data is collected, it can be sent to InfluxDB. For visualization, you can use open-source tools like Grafana.
Initially, we used Prometheus and Grafana for alerts. But, it wasn't feasible to handle logs and other types of databases. We then switched to InfluxDB due to its user interface, which allowed us to customize alerts, data visualization, and filtering for monitoring purposes.
I'm using InfluxDB to store documents related to the database and to populate data through their funnel.
I use InfluxDB for querying based on time ranges and window operations.
Our usage of Influx is very specific. We use it for our casino stack and applications. We use it for monitoring, logging, and metrics and trend analysis for player wagering. It is for casino data. We correlate all that data and generate reports for data warehousing. So, we use it massively in our stack for the casino for a lot of things. We haven't yet migrated to Influx 2.0. We are still using Influx 1.8 because we have multiple workloads in production. It is going to take some time, and we need to ensure that the latest one is stable and the framework also brings a lot of different languages. We use it on-premise and in the cloud. We have both. It is a private cloud on AWS.
We use InfluxDB for monitoring all services we have. We have a lot of services.
We don't use a managed service. Rather, we manage it ourselves. We have deployed it and right now, we are using it for log aggregation with a two-week retention policy.
I primarily use the solution for database storage.