The backdrop to all this is that open source Redis is an incredibly popular platform. Ranked among the top 10 databases by db-Engines, according to Sumologic, it is also the most popular database deployed on AWS. And pouring it on, Stack Overflow surveys of its community listed Redis as the “most loved” database by developers for the last five years running. Each of the major cloud providers offer their own Redis-based caching services based on the open source version. Developers love Redis because it meets developers where they live. It supports the data types that developers frequently work with, such as hashes, lists, sets, strings, and sorted sets. And, secondly, Redis supports the languages that are popular with developers, such as C, C++, C#, JavaScript, Java, Go, Objective-C, Python, and PHP. Versatility has long been key to Redis’ success. It’s most commonly used as an in-memory cache that sits alongside a transactional database, such as SQL Server, MySQL, or Oracle. It offloads the real-time processing from back end databases. That’s a task that’s as old as the transaction monitors of the 1990s and the in-memory object stores (which were primitive key/value data stores) of the early 2000s. The challenge, however, is when developers use Redis cache for purposes that it was not intended, with time series databases for IoT data being a prime example – and popular use case. Redis cache ingests the data rapidly, but the problem is that it lacks durability and persistence; when the node goes down, the data is lost. Open source Redis can write data to an append-only file on disk, but that measure is similarly vulnerable if the node goes down. Until now, when it came to Redis as a full-fledged in-memory NoSQL or multimodel database, Redis Enterprise was the only game in town. Redis Labs has staked its business on offering answers for developers requiring more than cache. Compared to open source Redis, Redis Enterprise supports more granular high availability approaches; tiering of data to SSD Flash storage; fully geodistributed (multimaster) database operation through active-active replication; multi-cloud support; and support of Redis Modules, which add extensibility to the database (e.g., support of search, graph data, embedded SQLite, JSON and other capabilities). Redis Enterprise Cloud runs on all three major public clouds – through the marketplaces on AWS and Azure; and as a jointly supported offering on Google Cloud. And the need for a Redis database is what prompted AWS to introduce MemoryDB – although at this point, the capabilities of MemoryDB and Redis Enterprise markedly differ. For instance, Redis Enterprise offers tiered storage to Flash, a capability that is not on the initial release. A major differentiator with MemoryDB, however, is its approach to data persistence. It employs a multi-AZ transaction log to keep data durable and enable replacement and recovery with no data loss. Importantly, the log does not run on MemoryDB’s database nodes. Once MemoryDB commits a write to the underlying transaction log, it is propagated to replica nodes with guaranteed eventual consistency. Customers can launch MemoryDB clusters using AWS Graviton2 instances. It will perform microsecond reads and single-digit millisecond writes thanks, not only to relying on memory, but with the lightweight transaction log approach. As noted, while tiering cooler data to Flash is not currently supported, we wouldn’t be surprised if it gets supported in a future release. Disclosure: AWS is a dbInsight client.
