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.

The best features of InfluxDB that I found most valuable during my projects are the time series capabilities because it is a time series database, allowing me to monitor real-time metrics of all network details. Networking generates a very high volume of data where even a second's delay can cause significant issues, as seen in the recent Cloudflare and Amazon outages. If the network is not operating properly, you cannot rely on the servers. Another important feature I found in InfluxDB is that while it can break under very high throughput data flow, it can still withstand a specific amount. Additionally, another helpful feature was InfluxDB's straightforward approach to aggregating or downsampling and analyzing KPIs over time, which was essential for identifying trends and performance degradation patterns. Overall, InfluxDB delivered excellent performance, stability, and simplicity for telemetry-driven use cases.

InfluxDB positively impacted my organization as we were working on the LEO satellite KPI monitoring project. With InfluxDB's help, we were able to parse the network details for almost a lakh of probes, which greatly helped our business grow and facilitated our stability in the market.

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.

I have been using InfluxDB for quite a long period of time, approximately two years, and the last time I used InfluxDB was in July, around four months back from now.

In my experience, InfluxDB has been stable. There were a few instances it broke down when I attempted to parse a large amount of data at once. However, after integrating Kafka, it never broke again, as Kafka handled messages and metrics appropriately, decreasing the message throughput.

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.

I didn't have to reach out to customer support of InfluxDB, as it was relatively easy for me to integrate; therefore, I had no reason to contact customer support.

I have used almost all types of databases including NoSQL and SQL databases such as MongoDB, PostgreSQL, and PSQL, and I switched to InfluxDB because it was better than other databases for time series data because I needed live feeds from the network details I was gathering. The other databases I worked with weren't providing that very specific feature. Additionally, I was using Telegraf and Chronograf for visualization, and InfluxDB's direct integration with Chronograf made it very easy to use a database that already has built-in connectivity to the visualization tools.

The user interface of InfluxDB was pretty easily integrated using a server from where I installed InfluxDB from a Docker image on the official Docker website. I allowed the port numbers of InfluxDB to be customized through my Python script where all the network details were being stored initially. Therefore, I integrated the port number of the Kafka producer to InfluxDB's port number so that all the Kafka details and topics could pass those data towards InfluxDB.

I did evaluate other options before choosing InfluxDB, specifically PostgreSQL. However, since PostgreSQL doesn't offer direct connectivity with Chronograf, which I was using as my visualization tool, I opted for InfluxDB.

I would rate InfluxDB around an eight on a scale of one to ten.

I chose eight for my rating because it solved a lot of problems. It is a service for high throughput systems and a live database. However, I cannot ignore the challenges I faced while configuring the database with my message brokers, whether Rabbit or Kafka, because the documentation is not properly provided. Additionally, as I mentioned, having a NoSQL version of InfluxDB would make it better for those without SQL skills.

From a financial perspective, I felt that InfluxDB was cheaper than other SQL databases I have used, including PostgreSQL and PSQL. InfluxDB has been quite economical for our needs.

My advice for others looking into using InfluxDB is to be efficient and know the purpose of using it. Just because it is cheap doesn't mean it is better than other databases. While it is certainly effective, PostgreSQL may be better for storage needs. If you lack NoSQL skills, you may not use InfluxDB properly. It is crucial to read through the entire documentation and search online for integrating InfluxDB with other optimization tools and resources. I provided an overall rating of eight for InfluxDB.

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.

The searching is useful for me because the query is easy to use and very stable, and it is comfortable to use to search for the different metrics.

InfluxDB has positively impacted my organization by solving a monitoring problem that we had, coming up with a solution since we did not have any monitoring system, allowing us to build one from scratch.

The impact includes time saved because with the metrics we can easily troubleshoot a lot of the incidents with the network, making it really useful, and we have the ability to gather a lot of metrics.

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.

My advice for others looking into using InfluxDB is to use it the same way I did, because it is really stable, easy and friendly to use, and it is a great product overall.

I gave this product a rating of 8 out of 10.

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 offers a database similar to an Excel data sheet, where we can select different data in different fields.

The Excel-like feature of InfluxDB will be beneficial for my greenhouse project, in which I have divided data of different sensors in different boxes so that it is easy to locate that box and view data.

I have successfully completed my greenhouse project with the help of InfluxDB to visualize the data in the dashboard, and it is beneficial for me.

Visualizing my data on a web dashboard helps, as it also gives the data of how it is changing with time, and it also stores data for the future for AI.

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.

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.

It is very stable, with no reliability or downtime in InfluxDB; it is very good.

I have normally used InfluxDB and not utilized much scalability, so I haven't experienced the scalability of InfluxDB.

I don't know about the customer support of InfluxDB as I haven't needed help; that's why I haven't experienced customer service.

I haven't used any other solution than InfluxDB, as I appreciate InfluxDB very much.

I haven't evaluated any other options, as I appreciate InfluxDB, which is why I have chosen InfluxDB.

InfluxDB reduced my time to show data without any interruption, also reducing the number of people needed to manage the project; it is very good to have InfluxDB in my project.

I rate InfluxDB a seven out of ten.

It's good, which is why I have chosen it more than five, but it is not rated higher because I have to use Grafana with InfluxDB. I think if it gave visualized data in a better way, then it would have been rated more than seven.

If you want a normal, good visualization or database management system, you can go for InfluxDB, as it is very good software that can visualize the data.

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 mainly write and read data from InfluxDB. We perform very simple queries to do time series on a key, which is a unique ID of the vessel. We will select a vessel and select from time to time stamp. That’s what we do. InfluxDB’s core functionality is crucial as it allows us to store our data and execute queries with excellent response times.

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.

In total, I've been using InfluxDB for six years.

InfluxDB is extremely stable. It serves as the backbone of our application, and its stability is crucial. If InfluxDB stops or doesn’t scale, the entire application stops.

Scalability is critical. We’ve scaled on volume with seven years of continuous data without performance degradation. The scalability allows us to track vessel movements per second back to the application's conception in 2017.

We did not use a different solution for these use cases before InfluxDB.

The initial setup can be intimidating for newcomers, and there is a certain threshold needed due to the performance we get. However, once familiar with the setup, it becomes streamlined.

Four people were involved in the deployment process, and one person is now needed for maintenance.

We haven't gauged any measurable benefits; our company is more operational-focused.

We use the open-source version of InfluxDB, so it is free.

We evaluated using PostgreSQL and a time-series database in Amazon, though I can't recall its name.

InfluxDB works as expected with excellent scalability and stability, which is critical for our application. I rate InfluxDB ten out of ten overall.

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.

The platform operates very quickly. It is easy to configure, connect, and query and integrates seamlessly with Grafana.

I have been using InfluxDB for four years.

I have not experienced any stability issues with the product.

Approximately 20% of our team uses InfluxDB.

I recommend InfluxDB to others and rate it a ten.

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.

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.

I have been working with the product for five years.

My company has 20-30 admins and 4,000-5,000 users. We have around 15,000 servers.

If you deviate from their documentation, they may refuse to provide support, stating it's not covered under the agreement. Additionally, their response times are slow, and they often suggest purchasing premium support for quicker resolution.

When you opt for premium support, they usually assign dedicated consultants. This means that whenever you encounter a problem, you have direct access to experts whom you can call, email, or engage in a call to resolve issues.

The tool is an open-source product.

If you're considering using InfluxDB for the first time, I recommend trying it. It's an open-source database with the option to purchase enterprise support.
When purchasing the TICK stack, I recommend you opt for premium support. Premium support can be beneficial, particularly when encountering configuration issues or other challenges. With premium support, you can quickly reach out for assistance via phone and work towards resolving any issues promptly. Otherwise, you may wait for up to another week to resolve the problem.

Learning to use InfluxDB is not necessarily easy for a beginner. It requires some understanding, especially in areas like automation and scripting.

I would rate it as an open-source tool around seven to eight out of ten. You only need to spend money on the resources, not much on the product itself. Essentially, you need to invest in the database.