InfluxDB Cloud Serverless

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.