Redis logo

Redis

An in-memory database that persists on disk
15K
10K
+ 1
3.8K

What is 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.
Redis is a tool in the In-Memory Databases category of a tech stack.
Redis is an open source tool with 40.1K GitHub stars and 15.7K GitHub forks. Here’s a link to Redis's open source repository on GitHub

Who uses Redis?

Companies
4338 companies reportedly use Redis in their tech stacks, including Airbnb, Uber, and Instagram.

Developers
10097 developers on StackShare have stated that they use Redis.

Redis Integrations

Datadog, Presto, EasyEngine, Tyk Cloud, and SignalFx are some of the popular tools that integrate with Redis. Here's a list of all 51 tools that integrate with Redis.

Why developers like Redis?

Here’s a list of reasons why companies and developers use Redis
Redis Reviews

Here are some stack decisions, common use cases and reviews by companies and developers who chose Redis in their tech stack.

Robert Zuber
Robert Zuber
CTO at CircleCI · | 22 upvotes · 228.2K views
atCircleCICircleCI
MongoDB
MongoDB
PostgreSQL
PostgreSQL
Redis
Redis
GitHub
GitHub
Amazon S3
Amazon S3

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
James Cunningham
James Cunningham
Operations Engineer at Sentry · | 22 upvotes · 155K views
atSentrySentry
Django
Django
Celery
Celery
PostgreSQL
PostgreSQL
Redis
Redis
#MessageQueue
#InMemoryDatabases

Sentry started as (and remains) an open-source project, growing out of an error logging tool built in 2008. That original build nine years ago was Django and Celery (Python’s asynchronous task codebase), with PostgreSQL as the database and Redis as the power behind Celery.

We displayed a truly shrewd notion of branding even then, giving the project a catchy name that companies the world over remain jealous of to this day: django-db-log. For the longest time, Sentry’s subtitle on GitHub was “A simple Django app, built with love.” A slightly more accurate description probably would have included Starcraft and Soylent alongside love; regardless, this captured what Sentry was all about.

#MessageQueue #InMemoryDatabases

See more
Russel Werner
Russel Werner
Lead Engineer at StackShare · | 19 upvotes · 245.5K views
atStackShareStackShare
React
React
Glamorous
Glamorous
Apollo
Apollo
Node.js
Node.js
Rails
Rails
Heroku
Heroku
GitHub
GitHub
Amazon S3
Amazon S3
Amazon CloudFront
Amazon CloudFront
Webpack
Webpack
CircleCI
CircleCI
Redis
Redis
#StackDecisionsLaunch
#SSR
#Microservices
#FrontEndRepoSplit

StackShare Feed is built entirely with React, Glamorous, and Apollo. One of our objectives with the public launch of the Feed was to enable a Server-side rendered (SSR) experience for our organic search traffic. When you visit the StackShare Feed, and you aren't logged in, you are delivered the Trending feed experience. We use an in-house Node.js rendering microservice to generate this HTML. This microservice needs to run and serve requests independent of our Rails web app. Up until recently, we had a mono-repo with our Rails and React code living happily together and all served from the same web process. In order to deploy our SSR app into a Heroku environment, we needed to split out our front-end application into a separate repo in GitHub. The driving factor in this decision was mostly due to limitations imposed by Heroku specifically with how processes can't communicate with each other. A new SSR app was created in Heroku and linked directly to the frontend repo so it stays in-sync with changes.

Related to this, we need a way to "deploy" our frontend changes to various server environments without building & releasing the entire Ruby application. We built a hybrid Amazon S3 Amazon CloudFront solution to host our Webpack bundles. A new CircleCI script builds the bundles and uploads them to S3. The final step in our rollout is to update some keys in Redis so our Rails app knows which bundles to serve. The result of these efforts were significant. Our frontend team now moves independently of our backend team, our build & release process takes only a few minutes, we are now using an edge CDN to serve JS assets, and we have pre-rendered React pages!

#StackDecisionsLaunch #SSR #Microservices #FrontEndRepoSplit

See more
John Kodumal
John Kodumal
CTO at LaunchDarkly · | 15 upvotes · 184.8K views
atLaunchDarklyLaunchDarkly
Amazon RDS
Amazon RDS
PostgreSQL
PostgreSQL
TimescaleDB
TimescaleDB
Patroni
Patroni
Consul
Consul
Amazon ElastiCache
Amazon ElastiCache
Amazon EC2
Amazon EC2
Redis
Redis
Amazon Kinesis
Amazon Kinesis
Kafka
Kafka

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
Dmitry Mukhin
Dmitry Mukhin
at Uploadcare · | 15 upvotes · 69.2K views
atUploadcareUploadcare
Google App Engine
Google App Engine
Python
Python
Redis
Redis
Amazon S3
Amazon S3
Amazon DynamoDB
Amazon DynamoDB
PostgreSQL
PostgreSQL

Uploadcare has built an infinitely scalable infrastructure by leveraging AWS. Building on top of AWS allows us to process 350M daily requests for file uploads, manipulations, and deliveries. When we started in 2011 the only cloud alternative to AWS was Google App Engine which was a no-go for a rather complex solution we wanted to build. We also didn’t want to buy any hardware or use co-locations.

Our stack handles receiving files, communicating with external file sources, managing file storage, managing user and file data, processing files, file caching and delivery, and managing user interface dashboards.

At its core, Uploadcare runs on Python. The Europython 2011 conference in Florence really inspired us, coupled with the fact that it was general enough to solve all of our challenges informed this decision. Additionally we had prior experience working in Python.

We chose to build the main application with Django because of its feature completeness and large footprint within the Python ecosystem.

All the communications within our ecosystem occur via several HTTP APIs, Redis, Amazon S3, and Amazon DynamoDB. We decided on this architecture so that our our system could be scalable in terms of storage and database throughput. This way we only need Django running on top of our database cluster. We use PostgreSQL as our database because it is considered an industry standard when it comes to clustering and scaling.

See more
Kir Shatrov
Kir Shatrov
Production Engineer at Shopify · | 13 upvotes · 146.8K views
atShopifyShopify
Docker
Docker
Kubernetes
Kubernetes
Google Kubernetes Engine
Google Kubernetes Engine
MySQL
MySQL
Redis
Redis
Memcached
Memcached

At Shopify, over the years, we moved from shards to the concept of "pods". A pod is a fully isolated instance of Shopify with its own datastores like MySQL, Redis, Memcached. A pod can be spawned in any region. This approach has helped us eliminate global outages. As of today, we have more than a hundred pods, and since moving to this architecture we haven't had any major outages that affected all of Shopify. An outage today only affects a single pod or region.

As we grew into hundreds of shards and pods, it became clear that we needed a solution to orchestrate those deployments. Today, we use Docker, Kubernetes, and Google Kubernetes Engine to make it easy to bootstrap resources for new Shopify Pods.

See more

Redis Alternatives & Comparisons

What are some alternatives to Redis?
Memcached
Memcached is an in-memory key-value store for small chunks of arbitrary data (strings, objects) from results of database calls, API calls, or page rendering.
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.
RabbitMQ
RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received.
Hazelcast
With its various distributed data structures, distributed caching capabilities, elastic nature, memcache support, integration with Spring and Hibernate and more importantly with so many happy users, Hazelcast is feature-rich, enterprise-ready and developer-friendly in-memory data grid solution.
Cassandra
Partitioning means that Cassandra can distribute your data across multiple machines in an application-transparent matter. Cassandra will automatically repartition as machines are added and removed from the cluster. Row store means that like relational databases, Cassandra organizes data by rows and columns. The Cassandra Query Language (CQL) is a close relative of SQL.
See all alternatives

Redis's Followers
10042 developers follow Redis to keep up with related blogs and decisions.
Apratim Sharma
pablopupulin
trackula_iran
SAMUEL MARQUES
Jeffery Brown
sylflo sylflo
Ahmet ÜK
Aykut Can T
var23rav
Anup Kallingal