HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
antirez
redis
C2009–2020
antirez / redis

redis

Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.

142Distinct people
165Mentions
3Explicit recommenders
169GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.

GitHub

Where it is used

  • Sidekiq — Sidekiq uses Redis as the storage engine for all job and operational data. It connects to Redis by default and provides guidance for production configuration. Source

What people are saying

Ah I see. I didn't realize it was old, I just picked server.c since it just sounded like it'd have a decent mix of stuff. I think the only 'taste' things I mentioned is the…

mehrdadn used a recommendation phrase. 3 indexed comments match. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 5:58:02 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year165 dated mentions

Observed mentions: 2009-09-03 00:45:38 UTC to 2020-06-30 21:42:49 UTC.

01020302009-01-01 00:00:00 UTC to 2010-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20092010-01-01 00:00:00 UTC to 2011-01-01 00:00:00 UTC (exclusive): 6 mentions; 1 submissions, 5 comments2011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 12 mentions; 3 submissions, 9 comments2012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 18 mentions; 5 submissions, 13 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 17 mentions; 3 submissions, 14 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 26 mentions; 5 submissions, 21 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 27 mentions; 8 submissions, 19 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 16 mentions; 3 submissions, 13 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2020

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20092009-01-01 00:00:00 UTC2010-01-01 00:00:00 UTC211
20102010-01-01 00:00:00 UTC2011-01-01 00:00:00 UTC615
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC1239
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC18513
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC12012
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC725
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC17314
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC26521
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC16214
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC27819
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC16313
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC606

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
This document serves as both a quick start guide to Redis and a detailed resource for building it from source. New to Redis? Start with What is Redis and Getting Started Ready to build from source? Jump to Build Redis from Source Want to contribute? See the Code contributions section and CONTRIBUTING.md Looking for detailed documentation? Navigate to redis.io/docs Table of contents What is Redis? Key use cases Why choose Redis? What is Redis Open Source? Getting started Redis starter projects Using Redis with client libraries Using Redis with redis-cli Using Redis with Redis Insight Redis data types, processing engines, and capabilities Community Build Redis from source Build and run Redis with all data structures - Ubuntu 20.04 (Focal) Build and run Redis with all data structures - Ubuntu 22.04 (Jammy) / 24.04 (Noble) Build and run Redis with all data structures - Debian 11 (Bullseye) / 12 (Bookworm) Build and run Redis with all data structures - AlmaLinux 8.10 / Rocky Linux 8.10 Build and run Redis with all data structures - AlmaLinux 9.5 / Rocky Linux 9.5 Build and run Redis with all data structures - macOS 13 (Ventura) and macOS 14 (Sonoma) Build and run Redis with all data structures - macOS 15 (Sequoia) Building Redis - flags and general notes Fixing build problems with dependencies or cached build options Fixing problems building 32 bit binaries Allocator Monotonic clock Verbose build Running Redis with TLS Code contributions Redis Trademarks What is Redis? For developers, who are building real-time data-driven applications, Redis is the preferred, fastest, and most feature-rich cache, data structure server, and document and vector query engine. Key use cases Redis excels in various applications, including: Caching: Supports multiple eviction policies, key expiration, and hash-field expiration. Distributed Session Store: Offers flexible session data modeling (string, JSON, hash). Data Structure Server: Provides low-level data structures (strings, lists, sets, hashes, sorted sets, JSON, etc.) with high-level semantics (counters, queues, leaderboards, rate limiters) and supports transactions & scripting. NoSQL Data Store: Key-value, document, and time series data storage. Search and Query Engine: Indexing for hash/JSON documents, supporting vector search, full-text search, geospatial queries, ranking, and aggregations via Redis Query Engine. Event Store & Message Broker: Implements queues (lists), priority queues (sorted sets), event deduplication (sets), streams, and pub/sub with probabilistic stream processing capabilities. Vector Store for GenAI: Integrates with AI applications (e.g. LangGraph, mem0) for short-term memory, long-term memory, LLM response caching (semantic caching), and retrieval augmented generation (RAG). Real-Time Analytics: Powers personalization, recommendations, fraud detection, and risk assessment. Why choose Redis? Redis is a popular choice for developers worldwide due to its combination of speed, flexibility, and rich feature set. Here's why people choose Redis for: Performance: Because Redis keeps data primarily in memory and uses efficient data structures, it achieves extremely low latency (often sub-millisecond) for both read and write operations. This makes it ideal for applications demanding real-time responsiveness. Flexibility: Redis isn't just a key-value store, it provides native support for a wide range of data structures and capabilities listed in What is Redis? Extensibility: Redis is not limited to the built-in data structures, it has a modules API that makes it possible to extend Redis functionality and rapidly implement new Redis commands Simplicity: Redis has a simple, text-based protocol and well-documented command set Ubiquity: Redis is battle tested in production workloads at a massive scale. There is a good chance you indirectly interact with Redis several times daily Versatility: Redis is the de facto standard for use cases such as: Caching: quickly access frequently used data without needing to query your primary database Session management: read and write user session data without hurting user experience or slowing down every API call Querying, sorting, and analytics: perform deduplication, full text search, and secondary indexing on in-memory data as fast as possible Messaging and interservice communication: job queues, message brokering, pub/sub, and streams for communicating between services Vector operations: Long-term and short-term LLM memory, RAG content retrieval, semantic caching, semantic routing, and vector similarity search In summary, Redis provides a powerful, fast, and flexible toolkit for solving a wide variety of data management challenges. If you want to know more, here is a list of starting points: Introduction to Redis data types The full list of Redis commands Redis for AI Redis documentation What is Redis Open Source? Redis Community Edition (Redis CE) was renamed Redis Open Source with the v8.0 release. Redis Ltd. also offers Redis Software, a self-managed software with additional compliance, reliability, and resiliency for enterprise scaling, and Redis Cloud, a fully managed service integrated with Google Cloud, Azure, and AWS for production-ready apps. Read more about the differences between Redis Open Source and Redis here. Getting started If you want to get up and running with Redis quickly without needing to build from source, use one of the following methods: Redis Cloud Official Redis Docker images (Alpine/Debian) docker run -d -p 6379:6379 redis:latest Redis binary distributions Snap Homebrew RPM Debian Redis quick start guides If you prefer to build Redis from source - see instructions below. Redis starter projects To get started as quickly as possible in your language of choice, use one of the following starter projects: Python (redis-py) C#/.NET (NRedisStack/StackExchange.Redis) Go (go-redis) JavaScript (node-redis) Java/Spring (Jedis) Using Redis with client libraries T
Read the full README on GitHub

What Hacker News says

17 sources
https://github.com/antirez/redis/blob/unstable/redis.conf#L4... # Command renaming. # It is possible to change the name of dangerous commands in a shared # environment. # For instance the CONFIG command may be renamed into something # hard to guess so that it will still be available for internal-use tools # but not available for general clients. # # Example: # # rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52 # # It is also possible to completely kill a command by renaming it into # an empty string: # # rename-command CONFIG "" I'm a big Redis fan, and have used most of its power, including the great HyperLogLog stuff, I never really looked at the CONFIG command and would not have imagined it would allow such things even. Is CONFIG commonly used? What are the use cases?
In A few things about Redis security
> C cannot - there is apparently no way that is both reasonably efficient and reasonable foolproof to write C code; if you have large scale examples written by more than one person[0], I would love to see them. Not easy. Sure. In that regard, I'm trying something in order to help in the case of C, but it is not intended specifically for the problem we're speaking (just strings and other data structures, not a "NodeJS for C"): https://github.com/faragon/libsrt > I concur C++ should be able to, but I again request large scale examples, because I've never seen any. Have you? Of course not. There were many years ago when servers were way slower than today. The problem is not solved for current web, obviously. "Solved", in the sense of having some framework for having low level stuff in the backend without doing a byzantine effort. The point i
Read the rest
s about how to break monopolies in the David vs Goliath sense. If you have the resources, go high level. > You have to define your terms. Is Lua high or low level? Well written Lua code that does not need millions of small objects seems to run to within x2 as slow as comparable C code when executed through LuaJIT2. I've seen well written Perl beat well written C in the past (the Perl was better written, but both were well written). Please note that I was speaking about extreme optimization, even avoiding filesystem I/O, and reducing memory copies to the minimum. So it is not about comparing C vs Perl doing disk I/O, but in pure calculous. High level languages, even using JIT, have an important data structure size overhead and also allocation issues (when handling 10^5-10^6 requests per second on a single thread), so even with properly optimized code you can have poor performance in comparison to low level languages with optimized data structures (e.g. libraries using low level data structures using indexes instead pointers, multiplexing buffers, allowing memory aliasing for allowing conversions in the same buffer, etc.). > With a language that so easily lets you shoot yourself in the foot like C or C++, this is not the case in practice, see, e.g., every C program ever written. Can you give the examples you're thinking of so we can discuss them? Write backends in C/C++ is nonsense, unless you want to handle 10-100x requests using same hardware. If your service allows to cover the expense, go high level. Of course :-) P.S. some low level backend stuff: Kore: https://news.ycombinator.com/item?id=9558196 Rwasa: https://news.ycombinator.com/item?id=9948749 Redis: https://github.com/antirez/redis (e.g. changing it in order to call the DB operations directly from same-process, without doing connections)
In “The Dream of Internet Freedom Is Dying”
Hello, I'm currently integrating, refactoring and fixing the original code, in the context of this branch: https://github.com/antirez/redis/commits/geo So far the code was simplified and polished, fixed (it did not returned the right set of elements in all the cases), GEORADIUS speed was improved. On the other side I removed all the JSON things and the Pub/Sub (IMHO is interesting to subscribe to areas to see objects entering/exiting them, not much to position updates since it's the same of doing PUBLISH+GEOADD from the client side). Added: GEOHASH to return a Geohash standard string from of a given element, mainly for interoperability. I'm also adding GEODIST (to calculate distances) and GEOPOS (to retrieve latitude/longitude of objects without the need to query for radius). The work will be available in the context of Redis 3.2, unless
Read the rest
I get mad and merge back into 3.0, which is unlikely but not impossible. EDIT: before of three days ago I was not aware of Geohashing at all, so if you have five mins to check the code, I'll be glad :-) Thanks. I'm pretty confident that it's ok now after I added a fuzzy test that replicates the feature (by brute forcing distance computation) in Tcl that checks against the Redis output, but still... EDIT2: wanted to add that I'm very glad Matt efforts are not going to be wasted and we are finally merging this.
In Redis Geo
uhh...when you mention NASA engineers and Google "actually making something" while adhering to strict code quality you seem to overlook the fact that NASA and Google are organizations with thousands of developers and notch is ONE GUY. And Tim Sweeney did a lot of development on Unreal 4 on his own[1]. The trade offs of structure & abandon can work at many scales, you don't have to be Google to do it. Likewise Redis[2] has largely been the work of a single developer, and isn't reckless. Now while Minecraft is a toy and Notch likely didn't start out with the thought to develop it into a business, that doesn't mean the value of its code is worthless. Yes the tradeoffs are there, but we shouldn't get carried away and start to believe you can only write "good" code if you have a thousand engineers. [1]http://www.tgdaily.com/business-and-law-fe
Read the rest
In Programming is terrible – Lessons learned from a life wasted (2013) [video]
Read the code yourself here: https://github.com/antirez/redis/blob/unstable/src/dict.c (It's a classic hashmap.) JSON in binary format? You mean BSON? Just use MongoDB at that point, or PostgreSQL with JSON support. Redis has tables to an extent, you don't need any more than that. Also, running on disk versus in memory is very different. Writing in SQLite is done to a Write-Ahead Log and then committed into the file slowly. Reads are done by building a schema to a set of pointer additions and finding objects in b-trees by scanning both the in-memory cache as well as objects on the hard drive. Totally, totally different. Just use the Redis Serialization feature instead. Or, better yet, use MongoDB/PostgreSQL/SQLite as intended. Aside: the whole point of the Structured Query Language is to take away the lowest level, most basic work from t
Read the rest
he programmer. That way, he or she can write the logic without worrying about how the logic is performed. Why redo all of that work? SQL exists for a reason: so you don't reinvent the wheel.
In Ask HN: What internal data structures does redis use to make it so fast?

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.