Reviews (51-68 of 68)
- Adoption of Redis, gave us the ability to realize our goal of digitally transforming the process of filing returns, generating bills, and tracking the movement of goods across states.
- Using Redis Enterprise, we were able to reduce the time it took to generate an e-way bill by more than 85%. Just as important, we were able to dramatically reduce the burden on our SQL database and API calls.
- Highly available persistent caching solution recognized for its seamless compatibility with Microsoft SQL Server and Consistent end-to-end response times below 40ms.
- Flexible data structures and commands for efficient application in use cases beyond caching.
- Session management is currently being handled in memory by our SQL server, but as the number of concurrent sessions during peak times moves from today’s average of 50,000 to an expected 100,000, we’ll need to implement more efficient session and authentication management likely within Redis Enterprise.
- Manage the complexity of data in many different structures ranging from relational, to logs, to raw text. Handling of Streaming data, large volume of transactions/requests and data movement.
- The functionalities like Joins (inner/outer join), Set operations (Union/Intersect/Minus), Transactions, Full ANSI SQL support, Constraints (like RDBMS) are not easily supported.
- Simple Key Value storage
- Easy interface compared to other databases
- Reliable performance characteristics
- Redis needs better distributed support. I know this is not the point, but a distributed Redis with some CAP tradeoffs would be useful
- Redis should be more clear on its pooling capabilities. Should you use a pool or just use a single connection?
- It would be nice if Redis had a better CLI
If you need something that can be written and read by multiple services, that is as fast as possible, use Redis. The simplicity is its biggest strength, and making it more complex will just ruin the product.
- Response time - the time taken to store or retrieve something from Redis is minuscule compared to most of the alternatives that we are aware of.
- Value for the money - every time we offload data storage to Redis it saves us money, compared to using something like MongoDB or AWS.
- Better documentation.
- Very, very fast due to the in-memory data store, which makes it highly scalable on rational-sized hardware.
- Fills a number of different use cases: can build message broadcast, task queues, sorted sets (i.e. leaderboards), and database caching all with the same tool.
- A robust third-party ecosystem of deployment options (like AWS) and libraries in a number of common programming languages.
- Can be difficult to set up as it scales past a single write node.
- While Redis can preserve state by writing to the file system in a couple of ways, it can still be cumbersome to standup a cluster with history.
- Cacheing APIs - this is where it shines for us
- Quick in memory database of key value pairs
- The tooling around Redis provides insight into what you are caching and provides easy methods to clear some caches and not all
- New versions of the tooling are not easy to install compared to previous generations
- Lots of versatility. We use it as a dumb store for string payloads, but can store a bunch of other data structures also.
- Easy to set up
- Persistence support isn't great. RDB is useless for our case (job system). AOF has *huge* performance issues, particularly when reading the file on startup after a failure.
Redis allowed us to build very fast a small cluster of nodes (4) serving as a cache for storing web sessions.
Because of additional features of Redis (pub/sub, in memory Keystore), Redis was also identified as non-critical storage for some data.
- Redis is easy to learn and concepts are very simple. It's an in-memory storage with regular snapshots for data resiliency.
- Redis offers the possibility to act as a cache with limited but strong eviction set policies. LRU is the most common one.
- The pub/sub feature of Redis is an interesting alternative for efficient and fast data distribution when we don't need a central broker such as JMS. Obviously, it requires some analysis before choosing between the bunch of providers (JMS, Kafka, MQTT, AMQP, Redis, etc)
- Redis is sponsored by Redislab which limit its functionalities. This is normal but they should push for a graphical tool for Redis monitoring. This tool is available for the enterprise edition, it would be nice to have a core version for the community
- I don't know if Redis is available in containers, this might be interesting to have such capability
I don't recommend Redis if you are looking for something else than a key/value store. Even if Redis claims to be a "data structure server", you might face limitations while dealing with other data structures.
- key - value logic
- no SQL structure
- really speedy queries
- need an initial implementation
- without a correct key - value queries do not perform
- need a change of the actual application to move from SQL to Redis
- Low latency: As it is in memory, saves on I/O
- Repetitive: As part of ETL we use it to address resolution, .i.e. given an address, find a representative lat long for it. As millions of rows are ETLed every day, there is high chance that they repeat. Having in-memory helps again
- Point queries: WHERE age BETWEEN 10 and 30 is a range query and WHERE age = 15 is a point query. We use it only for point queries
- When dataset is small enough to fit in-memory and get full benefits of reduced I/O
- Need of rich data structures for complex querying
- Speed of in-memory store and durability by disk at the same time
- Declarative querying like SQL
- Tools for monitoring and identifying performance bottlenecks
- Key schema design can be tricky and heavily impacts the performance (leading to key scans)
- Low latency queries are a must
- Frequent point queries as it is a key-value store
- Use awesome Redis Modules (Redis Search, Redis Neural Net, Redis ML, Redis-Secondary, Redis Graph)
- When values are complex objects and not simple data structures. Document stores are better for those work loads
- Huge data and not feasible (due to budget constraints) to scale up RAM
- Quick lookup/interaction with data
- Excellent key-value storage where everything is treated as a hashtable
- Cheap alternative to other storage solutions
- Mass amounts of storage is supported
- The backup and recovery solutions are not ideal; recommend backing it with a more durable option
- The spin up to find an optimal setup for performance takes time and testing
- No super user friendly GUI application to interact with the data
- Caching - that's what it's built to do, and it does it well.
- Performance - pretty much everything happens in memory, so it's blazing fast.
- Atomic operations - when you need a distributed counter, Redis is a great option for avoiding race conditions across services/servers.
- Blocking calls - polling for changes kinda stinks, and Redis gives you the option to perform blocking calls that immediately return when data is ready.
- Complex querying - Redis is not a relational database, and should not be used as one.
- Clustering - this is always a complicated topic, but it could be made more simple.
Another place where we are using redis is for our caching, since we deal with high volumes of data, we use redis as a caching mechanism and it has done wonders for us.
- Speed. The very fact that it is used for caching systems should verify that it must be really fast.
- Pubsub. Though there might be alternatives that solve this problem as well, in our case redis did it accurately and without any data loss.
- Redis has a couple of data types that aren't available in other systems. The most useful one according to me is lists; I haven't been able to take full advantage of this feature yet though.
- Redis may not be for you if you want to deploy a cluster but don't have at least 5 different devices since it requires at least 3 masters and 2 slaves for the configuration to work.
- The reason redis is really fast is because it resides in your RAM hence it might be a problem when you have an application that needs a lot of RAM and it has to share that with redis. This will depend on the size of your application, users using the applications and obviously the amount of RAM you have.
Redis Scorecard Summary
Feature Scorecard Summary
According to the vendor, Redis is an in-memory multi-model database that supports multiple data structures such as strings, hashes, lists, sets, sorted sets with range queries, bitmaps, hyperloglogs and geospatial indexes with radius queries. Redis has built-in replication, Lua scripting, LRU eviction, transactions and different levels of on-disk persistence, and provides high availability and automatic partitioning with Redis Cluster.
Redis combines in-memory, schema-less design with optimized data structures and versatile modules that adapt to your data needs. The result is an adept, high performance, multi-purpose database that scales easily like a simple key/value data store but delivers sophisticated functionality with great simplicity, according to the vendor.
Redis also enables data persistence and high availability through replication and backups. Redis Enterprise is built from the ground up to serve as a system of record for any application.
Redis Support Options
|Free Version||Paid Version|
|Video Tutorials / Webinar|
Redis Technical Details
|Deployment Types:||On-premise, SaaS|
|Operating Systems:||Windows, Linux, Mac|
|Mobile Application:||Apple iOS, Android, Windows Phone, Blackberry, Mobile Web|