Alternatives to InfluxDB logo

Alternatives to InfluxDB

TimescaleDB, Redis, MongoDB, Elasticsearch, and Prometheus are the most popular alternatives and competitors to InfluxDB.
819
848
+ 1
161

What is InfluxDB and what are its top alternatives?

InfluxDB is a scalable datastore for metrics, events, and real-time analytics. It has a built-in HTTP API so you don't have to write any server side code to get up and running. InfluxDB is designed to be scalable, simple to install and manage, and fast to get data in and out.
InfluxDB is a tool in the Databases category of a tech stack.
InfluxDB is an open source tool with 21.6K GitHub stars and 3K GitHub forks. Here’s a link to InfluxDB's open source repository on GitHub

Top Alternatives to InfluxDB

  • TimescaleDB

    TimescaleDB

    TimescaleDB: An open-source database built for analyzing time-series data with the power and convenience of SQL — on premise, at the edge, or in the cloud. ...

  • Redis

    Redis

    Redis is an open source, BSD licensed, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets. ...

  • MongoDB

    MongoDB

    MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...

  • Elasticsearch

    Elasticsearch

    Elasticsearch is a distributed, RESTful search and analytics engine capable of storing data and searching it in near real time. Elasticsearch, Kibana, Beats and Logstash are the Elastic Stack (sometimes called the ELK Stack). ...

  • Prometheus

    Prometheus

    Prometheus is a systems and service monitoring system. It collects metrics from configured targets at given intervals, evaluates rule expressions, displays the results, and can trigger alerts if some condition is observed to be true. ...

  • Zabbix

    Zabbix

    Zabbix is a mature and effortless enterprise-class open source monitoring solution for network monitoring and application monitoring of millions of metrics. ...

  • KairosDB

    KairosDB

    KairosDB is a fast distributed scalable time series database written on top of Cassandra. ...

  • Graphite

    Graphite

    Graphite does two things: 1) Store numeric time-series data and 2) Render graphs of this data on demand ...

InfluxDB alternatives & related posts

TimescaleDB logo

TimescaleDB

137
226
41
Scalable and reliable time-series SQL database optimized for fast ingest and complex queries. Built on PostgreSQL.
137
226
+ 1
41
PROS OF TIMESCALEDB
  • 8
    Open source
  • 7
    Easy Query Language
  • 6
    Time-series data analysis
  • 5
    Established postgresql API and support
  • 4
    Reliable
  • 2
    Paid support for automatic Retention Policy
  • 2
    Fast and scalable
  • 2
    Chunk-based compression
  • 2
    Postgres integration
  • 2
    High-performance
  • 1
    Case studies
CONS OF TIMESCALEDB
  • 2
    Licensing issues when running on managed databases

related TimescaleDB posts

John Kodumal

As we've evolved or added additional infrastructure to our stack, we've biased towards managed services. Most new backing stores are Amazon RDS instances now. We do use self-managed PostgreSQL with TimescaleDB for time-series data—this is made HA with the use of Patroni and Consul.

We also use managed Amazon ElastiCache instances instead of spinning up Amazon EC2 instances to run Redis workloads, as well as shifting to Amazon Kinesis instead of Kafka.

See more
Mauro Bennici
CTO at You Are My GUide · | 7 upvotes · 39.3K views

PostgreSQL plus TimescaleDB allow us to concentrate the business effort on how to analyze valuable data instead of manage them on IT side. We are now able to ingest thousand of social shares "managed" data without compromise the scalability of the system or the time query. TimescaleDB is transparent to PostgreSQL , so we continue to use the same SQL syntax without any changes. At the same time, because we need to manage few document objects we dismissed the MongoDB cluster.

See more
Redis logo

Redis

38.3K
28.1K
3.9K
An in-memory database that persists on disk
38.3K
28.1K
+ 1
3.9K
PROS OF REDIS
  • 877
    Performance
  • 535
    Super fast
  • 511
    Ease of use
  • 442
    In-memory cache
  • 321
    Advanced key-value cache
  • 190
    Open source
  • 179
    Easy to deploy
  • 163
    Stable
  • 153
    Free
  • 120
    Fast
  • 40
    High-Performance
  • 39
    High Availability
  • 34
    Data Structures
  • 32
    Very Scalable
  • 23
    Replication
  • 20
    Great community
  • 19
    Pub/Sub
  • 17
    "NoSQL" key-value data store
  • 14
    Hashes
  • 12
    Sets
  • 10
    Sorted Sets
  • 9
    Lists
  • 8
    BSD licensed
  • 8
    NoSQL
  • 7
    Async replication
  • 7
    Integrates super easy with Sidekiq for Rails background
  • 7
    Bitmaps
  • 6
    Open Source
  • 6
    Keys with a limited time-to-live
  • 5
    Strings
  • 5
    Lua scripting
  • 4
    Awesomeness for Free!
  • 4
    Hyperloglogs
  • 3
    outstanding performance
  • 3
    Runs server side LUA
  • 3
    Networked
  • 3
    LRU eviction of keys
  • 3
    Written in ANSI C
  • 3
    Feature Rich
  • 3
    Transactions
  • 2
    Data structure server
  • 2
    Performance & ease of use
  • 1
    Existing Laravel Integration
  • 1
    Automatic failover
  • 1
    Easy to use
  • 1
    Object [key/value] size each 500 MB
  • 1
    Simple
  • 1
    Channels concept
  • 1
    Scalable
  • 1
    Temporarily kept on disk
  • 1
    Dont save data if no subscribers are found
  • 0
    Jk
CONS OF REDIS
  • 12
    Cannot query objects directly
  • 1
    No WAL
  • 1
    No secondary indexes for non-numeric data types

related Redis posts

Robert Zuber

We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

See more

I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.

We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.

Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis  for cache and other time sensitive operations.

We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.

Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.

See more
MongoDB logo

MongoDB

56.7K
46.4K
4.1K
The database for giant ideas
56.7K
46.4K
+ 1
4.1K
PROS OF MONGODB
  • 823
    Document-oriented storage
  • 589
    No sql
  • 545
    Ease of use
  • 463
    Fast
  • 405
    High performance
  • 253
    Free
  • 214
    Open source
  • 178
    Flexible
  • 140
    Replication & high availability
  • 108
    Easy to maintain
  • 40
    Querying
  • 36
    Easy scalability
  • 35
    Auto-sharding
  • 34
    High availability
  • 30
    Map/reduce
  • 26
    Document database
  • 24
    Easy setup
  • 24
    Full index support
  • 15
    Reliable
  • 14
    Fast in-place updates
  • 13
    Agile programming, flexible, fast
  • 11
    No database migrations
  • 7
    Enterprise
  • 7
    Easy integration with Node.Js
  • 5
    Enterprise Support
  • 4
    Great NoSQL DB
  • 3
    Aggregation Framework
  • 3
    Support for many languages through different drivers
  • 3
    Drivers support is good
  • 2
    Schemaless
  • 2
    Fast
  • 2
    Awesome
  • 2
    Managed service
  • 2
    Easy to Scale
  • 1
    Consistent
CONS OF MONGODB
  • 5
    Very slowly for connected models that require joins
  • 3
    Not acid compliant
  • 1
    Proprietary query language

related MongoDB posts

Jeyabalaji Subramanian

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Robert Zuber

We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

See more
Elasticsearch logo

Elasticsearch

23.9K
17.9K
1.6K
Open Source, Distributed, RESTful Search Engine
23.9K
17.9K
+ 1
1.6K
PROS OF ELASTICSEARCH
  • 321
    Powerful api
  • 311
    Great search engine
  • 231
    Open source
  • 213
    Restful
  • 200
    Near real-time search
  • 96
    Free
  • 83
    Search everything
  • 54
    Easy to get started
  • 45
    Analytics
  • 26
    Distributed
  • 6
    Fast search
  • 5
    More than a search engine
  • 3
    Great docs
  • 3
    Awesome, great tool
  • 3
    Easy to scale
  • 2
    Intuitive API
  • 2
    Great piece of software
  • 2
    Fast
  • 2
    Nosql DB
  • 2
    Easy setup
  • 2
    Highly Available
  • 2
    Document Store
  • 2
    Great customer support
  • 1
    Reliable
  • 1
    Not stable
  • 1
    Potato
  • 1
    Open
  • 1
    Github
  • 1
    Elaticsearch
  • 1
    Actively developing
  • 1
    Responsive maintainers on GitHub
  • 1
    Ecosystem
  • 1
    Scalability
  • 0
    Easy to get hot data
  • 0
    Community
CONS OF ELASTICSEARCH
  • 6
    Diffecult to get started
  • 5
    Resource hungry
  • 4
    Expensive
  • 3
    Hard to keep stable at large scale

related Elasticsearch posts

Tim Abbott

We've been using PostgreSQL since the very early days of Zulip, but we actually didn't use it from the beginning. Zulip started out as a MySQL project back in 2012, because we'd heard it was a good choice for a startup with a wide community. However, we found that even though we were using the Django ORM for most of our database access, we spent a lot of time fighting with MySQL. Issues ranged from bad collation defaults, to bad query plans which required a lot of manual query tweaks.

We ended up getting so frustrated that we tried out PostgresQL, and the results were fantastic. We didn't have to do any real customization (just some tuning settings for how big a server we had), and all of our most important queries were faster out of the box. As a result, we were able to delete a bunch of custom queries escaping the ORM that we'd written to make the MySQL query planner happy (because postgres just did the right thing automatically).

And then after that, we've just gotten a ton of value out of postgres. We use its excellent built-in full-text search, which has helped us avoid needing to bring in a tool like Elasticsearch, and we've really enjoyed features like its partial indexes, which saved us a lot of work adding unnecessary extra tables to get good performance for things like our "unread messages" and "starred messages" indexes.

I can't recommend it highly enough.

See more
Tymoteusz Paul
Devops guy at X20X Development LTD · | 21 upvotes · 4.3M views

Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I've decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on "live-example" of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

It always starts with an app, whatever it may be and reading the readmes available while Vagrant and VirtualBox is installing and updating. Following that is the first hurdle to go over - convert all the instruction/scripts into Ansible playbook(s), and only stopping when doing a clear vagrant up or vagrant reload we will have a fully working environment. As our Vagrant environment is now functional, it's time to break it! This is the moment to look for how things can be done better (too rigid/too lose versioning? Sloppy environment setup?) and replace them with the right way to do stuff, one that won't bite us in the backside. This is the point, and the best opportunity, to upcycle the existing way of doing dev environment to produce a proper, production-grade product.

I should probably digress here for a moment and explain why. I firmly believe that the way you deploy production is the same way you should deploy develop, shy of few debugging-friendly setting. This way you avoid the discrepancy between how production work vs how development works, which almost always causes major pains in the back of the neck, and with use of proper tools should mean no more work for the developers. That's why we start with Vagrant as developer boxes should be as easy as vagrant up, but the meat of our product lies in Ansible which will do meat of the work and can be applied to almost anything: AWS, bare metal, docker, LXC, in open net, behind vpn - you name it.

We must also give proper consideration to monitoring and logging hoovering at this point. My generic answer here is to grab Elasticsearch, Kibana, and Logstash. While for different use cases there may be better solutions, this one is well battle-tested, performs reasonably and is very easy to scale both vertically (within some limits) and horizontally. Logstash rules are easy to write and are well supported in maintenance through Ansible, which as I've mentioned earlier, are at the very core of things, and creating triggers/reports and alerts based on Elastic and Kibana is generally a breeze, including some quite complex aggregations.

If we are happy with the state of the Ansible it's time to move on and put all those roles and playbooks to work. Namely, we need something to manage our CI/CD pipelines. For me, the choice is obvious: TeamCity. It's modern, robust and unlike most of the light-weight alternatives, it's transparent. What I mean by that is that it doesn't tell you how to do things, doesn't limit your ways to deploy, or test, or package for that matter. Instead, it provides a developer-friendly and rich playground for your pipelines. You can do most the same with Jenkins, but it has a quite dated look and feel to it, while also missing some key functionality that must be brought in via plugins (like quality REST API which comes built-in with TeamCity). It also comes with all the common-handy plugins like Slack or Apache Maven integration.

The exact flow between CI and CD varies too greatly from one application to another to describe, so I will outline a few rules that guide me in it: 1. Make build steps as small as possible. This way when something breaks, we know exactly where, without needing to dig and root around. 2. All security credentials besides development environment must be sources from individual Vault instances. Keys to those containers should exist only on the CI/CD box and accessible by a few people (the less the better). This is pretty self-explanatory, as anything besides dev may contain sensitive data and, at times, be public-facing. Because of that appropriate security must be present. TeamCity shines in this department with excellent secrets-management. 3. Every part of the build chain shall consume and produce artifacts. If it creates nothing, it likely shouldn't be its own build. This way if any issue shows up with any environment or version, all developer has to do it is grab appropriate artifacts to reproduce the issue locally. 4. Deployment builds should be directly tied to specific Git branches/tags. This enables much easier tracking of what caused an issue, including automated identifying and tagging the author (nothing like automated regression testing!).

Speaking of deployments, I generally try to keep it simple but also with a close eye on the wallet. Because of that, I am more than happy with AWS or another cloud provider, but also constantly peeking at the loads and do we get the value of what we are paying for. Often enough the pattern of use is not constantly erratic, but rather has a firm baseline which could be migrated away from the cloud and into bare metal boxes. That is another part where this approach strongly triumphs over the common Docker and CircleCI setup, where you are very much tied in to use cloud providers and getting out is expensive. Here to embrace bare-metal hosting all you need is a help of some container-based self-hosting software, my personal preference is with Proxmox and LXC. Following that all you must write are ansible scripts to manage hardware of Proxmox, similar way as you do for Amazon EC2 (ansible supports both greatly) and you are good to go. One does not exclude another, quite the opposite, as they can live in great synergy and cut your costs dramatically (the heavier your base load, the bigger the savings) while providing production-grade resiliency.

See more
Prometheus logo

Prometheus

2.3K
2.7K
233
An open-source service monitoring system and time series database, developed by SoundCloud
2.3K
2.7K
+ 1
233
PROS OF PROMETHEUS
  • 43
    Powerful easy to use monitoring
  • 39
    Flexible query language
  • 32
    Dimensional data model
  • 26
    Alerts
  • 22
    Active and responsive community
  • 21
    Extensive integrations
  • 19
    Easy to setup
  • 12
    Beautiful Model and Query language
  • 7
    Easy to extend
  • 6
    Nice
  • 3
    Written in Go
  • 2
    Good for experimentation
  • 1
    Easy for monitoring
CONS OF PROMETHEUS
  • 11
    Just for metrics
  • 6
    Needs monitoring to access metrics endpoints
  • 5
    Bad UI
  • 3
    Not easy to configure and use
  • 2
    Requires multiple applications and tools
  • 2
    Written in Go
  • 2
    Supports only active agents
  • 1
    TLS is quite difficult to understand

related Prometheus posts

Conor Myhrvold
Tech Brand Mgr, Office of CTO at Uber · | 14 upvotes · 2.8M views

Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

https://eng.uber.com/m3/

(GitHub : https://github.com/m3db/m3)

See more

We have Prometheus as a monitoring engine as a part of our stack which contains Kubernetes cluster, container images and other open source tools. Also, I am aware that Sysdig can be integrated with Prometheus but I really wanted to know whether Sysdig or sysdig+prometheus will make better monitoring solution.

See more
Zabbix logo

Zabbix

499
684
55
Track, record, alert and visualize performance and availability of IT resources
499
684
+ 1
55
PROS OF ZABBIX
  • 14
    Free
  • 7
    Alerts
  • 5
    Service/node/network discovery
  • 4
    Templates
  • 4
    Base metrics from the box
  • 3
    Multi-dashboards
  • 3
    SMS/Email/Messenger alerts
  • 2
    Supports Graphs ans screens
  • 2
    Support proxies (for monitoring remote branches)
  • 2
    Grafana plugin available
  • 1
    API available for creating own apps
  • 1
    Templates free available (Zabbix Share)
  • 1
    Works with multiple databases
  • 1
    Supports large variety of Operating Systems
  • 1
    Supports multiple protocols/agents
  • 1
    Complete Logs Report
  • 1
    Advanced integrations
  • 1
    Supports JMX (Java, Tomcat, Jboss, ...)
  • 1
    Perform website checking (response time, loading, ...)
CONS OF ZABBIX
  • 5
    The UI is in PHP
  • 2
    Puppet module is sluggish

related Zabbix posts

Shared insights
on
Datadog
Zabbix
Centreon

My team is divided on using Centreon or Zabbix for enterprise monitoring and alert automation. Can someone let us know which one is better? There is one more tool called Datadog that we are using for cloud assets. Of course, Datadog presents us with huge bills. So we want to have a comparative study. Suggestions and advice are welcome. Thanks!

See more
KairosDB logo

KairosDB

13
34
5
Fast Time Series Database on Cassandra
13
34
+ 1
5
PROS OF KAIROSDB
  • 1
    Time-Series data analysis
  • 1
    Easy setup
  • 1
    As fast as your cassandra/scylla cluster go
  • 1
    Easy Rest API
  • 1
    Open source
CONS OF KAIROSDB
    Be the first to leave a con

    related KairosDB posts

    Graphite logo

    Graphite

    352
    349
    39
    A highly scalable real-time graphing system
    352
    349
    + 1
    39
    PROS OF GRAPHITE
    • 16
      Render any graph
    • 9
      Great functions to apply on timeseries
    • 7
      Well supported integrations
    • 5
      Includes event tracking
    • 2
      Rolling aggregation makes storage managable
    CONS OF GRAPHITE
      Be the first to leave a con

      related Graphite posts

      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 14 upvotes · 2.8M views

      Why we spent several years building an open source, large-scale metrics alerting system, M3, built for Prometheus:

      By late 2014, all services, infrastructure, and servers at Uber emitted metrics to a Graphite stack that stored them using the Whisper file format in a sharded Carbon cluster. We used Grafana for dashboarding and Nagios for alerting, issuing Graphite threshold checks via source-controlled scripts. While this worked for a while, expanding the Carbon cluster required a manual resharding process and, due to lack of replication, any single node’s disk failure caused permanent loss of its associated metrics. In short, this solution was not able to meet our needs as the company continued to grow.

      To ensure the scalability of Uber’s metrics backend, we decided to build out a system that provided fault tolerant metrics ingestion, storage, and querying as a managed platform...

      https://eng.uber.com/m3/

      (GitHub : https://github.com/m3db/m3)

      See more

      A huge part of our continuous deployment practices is to have granular alerting and monitoring across the platform. To do this, we run Sentry on-premise, inside our VPCs, for our event alerting, and we run an awesome observability and monitoring system consisting of StatsD, Graphite and Grafana. We have dashboards using this system to monitor our core subsystems so that we can know the health of any given subsystem at any moment. This system ties into our PagerDuty rotation, as well as alerts from some of our Amazon CloudWatch alarms (we’re looking to migrate all of these to our internal monitoring system soon).

      See more