The Hidden Costs of Redis

Hidden Costs of Redis

Redis has been one of the most popular in-memory key-value stores according to Stack Overflow’s Developer Survey. The popularity of open source Redis can be attributed to the perception that Redis is a “low cost” alternative to commercial software. While the software is free to download and use, the true costs of running Redis in a production environment are unfortunately not realized in the first few months. However, as companies grow, so does their data — as well as their performance requirements – and that is when Redis runs into speed bumps. We see numerous companies running into issues with Redis at scale, where there is a significant drop in performance, and hardware costs begin to pile up. Redis is also much harder to use at scale; no transaction support across shards being the primary issue.

A Redis instance runs on a single thread and requires the user to create a new Redis instance for each additional thread of computation. In contrast, a single VoltDB instance can represent a database that is across multiple threads and multiple physical machines. With open source Redis; the customer has to configure replication, sharding and high availability themselves (using Redis Sentinel) and code their applications to deal with the additional complexity. This takes a lot of time and ties up valuable resources from your app dev team.

VoltDB was architected to deliver real-time intelligent decisions on fast data with built-in machine learning. VoltDB can scale with ease and still offer blazing fast performance at limitless scale. Here’s why a leading telecom solutions provider recently moved from Redis to VoltDB:

  • Much lower hardware footprint / lower cost — They were able to use less servers than Redis to store the same data: 20 VoltDB servers were used to store the data that used to be stored on 70 Redis servers. Each server had 128GB RAM and 24 CPU cores. This resulted in a savings of over $1MM.
  • Considerably easier cluster management — They used to partition the data in their application, store it across different Redis clusters and then remember the partition table in the application. They were basically “manually” managing their data partitioning for the application.While with VoltDB the can do this automatically. When a node is down, the application has to direct the data to the backup partition in the application.
  • Full ANSI SQL capabilities — Redis doesn’t support SQL. The company had to implement “joins” in the application. They also needed to send and retrieve data multiple times to run a query. For example: they needed to match one table source (s1-mme) with 6 other XDR data sources. They had to send the s1-mme data 6 times to the Redis cluster to finish the match. In VoltDB, they only had to send the s1-mme data to VoltDB once in a stored procedure, and then join with all the 6 sources at once in the same stored procedure. This saved them a lot of network time and significantly reduced the complexity of their application. They also appreciated having the flexibility of having access to key-value capabilities with VoltDB.
  • Much faster query performance at scale — Redis just could not scale. Their application required 200k records per second for a join query, VoltDB far exceeded their KPI by doing 400k records per second.
  • Improved data loading — With VoltDB they could easily load 900,000 tps, while with Redis they could only load 800,000 tps per client per server.

It is only a matter of time that your business will grow along with your transactional processing needs, future proof your database investment by trying out VoltDB, and make sure you compare us to Redis at scale.

  • 184/A, Newman, Main Street Victor
  • 889 787 685 6