For more context pieter's original pull request is here: https://github.com/antirez/redis/pull/579
In Finally Redis collections are iterableantirez
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
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
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
- torvalds/linux · linked in 2 of the same 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, 3:30:57 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.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2009 | 2009-01-01 00:00:00 UTC | 2010-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2010 | 2010-01-01 00:00:00 UTC | 2011-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 12 | 3 | 9 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 18 | 5 | 13 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 12 | 0 | 12 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 17 | 3 | 14 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 26 | 5 | 21 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 16 | 2 | 14 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 27 | 8 | 19 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 16 | 3 | 13 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 6 | 0 | 6 |
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 GitHubWhat Hacker News says
12 sourcesSo, I'm trying to work out how this actually works, and thought I'd share my working (especially the reversed bit counter). No idea if my thinking out loud will help anyone else.
TL;DR: Because we count reversed, when the table shrinks (shrinking is done live, so the old table sticks around for a while) we will continue to iterate only from the position in the sequence where all of the masked bit combinations (those bits of the hash that are ignored in the smaller table) have already been explored. If we counted normally, then on a shrink we would end up skipping parts of the old table. Lines https://github.com/antirez/redis/blob/unstable/src/dict.c#L7... explain it perfectly, now I understand it.
Looking at the code, the increment works as follows:
counter |= ~mask;
counter = reverse(counter);
counter++;
counter = reverse
Read the rest
(counter);
The mask is the size of the hash table, minus one, so it always looks something like 0b00001111.
So the first step sets all the unimportant high bits. This means that, after the reverse, all of the unimportant low bits are set, which means an increment will set all of the unimportant bits to zero, and increment the important part of the reversed counter.
So this could be rewritten as:
counter = reverse(counter);
counter += (1 << (32-log_size));
counter = reverse(counter);
Sometimes a collection is made up of two tables, one larger, one smaller. There is an extra loop in each iteration to go through all of the elements of the larger table that share a hash prefix with the counter.
Now, why the reversed counter? If the table stays the same size, it doesn't matter what order you iterate. If the table grows, the prefix system still works, so that can't be it. So, by process of elimination, it must be necessary for collections that shrink.
Say we have an 8 element collection, and have iterated 000 and 100, and next is 010.
Then it starts shrinking to a 4 element collection. So next is 010 (which is interpreted as 10 in the new, smaller table, and 010 and 110 in the old table), then 01 (01, 001, 101), then 11 (11, 011, 111), then done.
Well, that worked (we visited all 8 places in the old table). Let's try a non-reverse increment.
000, 001. Next is 010.
Switch to size 4, and then visit (10,010,110), (11,011,111), done. We missed 100 and 101.
Okay, I'm happy. It sort of makes intuitive sense that if the shrink is what's important, and the high end is lost during the shrink, then incrementing from the high end will work better because throwing away the high end will still cover the whole range, as long as you still look at every bit in the thrown away section. Whereas incrementing from the low end will result in gaps.
Go from size 256 to 4 to really show it:
0,128,64,192|2,1,3,0
vs
0,1,2,3|0 (which examines only the top quarter of the old hash table)
Or to put it another way, look at this sequence: size 8: 0,4,2,6,1,5,3,7. The bottom bit is set only after all of the possiblities with the bottom bit reset have been explored. So if remove some of the top bits, either the bottom bits will not be set, or every combination of top bits with those bottom bits set will already have been explored.
A topic I rarely see (at least in depth, or in discussion) in stories/blogs about APIs is ID generation, i.e. best practices for creating access_token, resource ID and especially handling collisions.
The Flickr blog post [1], which featured a simple implementation of a ticket server, is so far one of the easiest and most secure to use.
Personally I don't feel comfortable using "hash of i++", "hash of ...", "i++", as they all "fall apart" when you need ids of different specifications (e.g. a 8-char ID, a 24-char token ID).
Anyone have two cents on this? I have a difficult time imagining that larger APIs just "live with" the chance of collision (even though it can be very low) - they must mitigate it somehow, right? combined probability (such as the nonce check and tokens on oauth1 requests)?
Actual ticket servers (e.g. [2], [3]) either int
Read the rest
roduce added complexity (and possibly latency) or needs a secondary code base. Regardless, the issue of scaling and latency is rarely touched upon, so if anyone have some input here, I'd greatly appreciate it.
EDIT: I've found two interesting links on the problem, [4] [5] (snippit'ed here [6]).
[1] http://code.flickr.net/2010/02/08/ticket-servers-distributed...
[2] https://github.com/twitter/snowflake
[3] https://github.com/boundary/flake
[4] http://boundary.com/blog/2012/01/12/flake-a-decentralized-k-...
[5] https://blog.twitter.com/2010/announcing-snowflake
[6] https://github.com/antirez/redis/pull/295#issuecomment-46734...
Looking at the benchmarks, I'm trying to rack my brain about how it outperforms redis consistently on every single benchmark for a simple associative map.
I don't know if this is likely, but it looks like redis doesn't lock memory [1], which means that the benchmarks could be explained by swapping. Depending on the type of shared memory used by whitedb, it could be that its pages are locked and immune to swapping.
[1] https://github.com/antirez/redis/issues/1177
In WhiteDB – Lightweight NoSQL database written in C, operating in main memoryWhat are you comparing that with? I find it fairly normal for C code dating from past, say 2000.
Also, one thing that made a negative impression on me is https://github.com/antirez/redis/blob/unstable/src/adlist.c:
/* Free the whole list.
*
* This function can't fail. */
void listRelease(list *list)
{
unsigned long len;
listNode *current, *next;
current = list->head;
...
If you write such a comment, you better make sure it is true. And no, an early "list == NULL" check is not the only thing missing.
In A quick look at the Redis source codeRedis is my favorite example of a very clean and beautiful example of C code, just the right amount of comments, good variable names. It is great work. You can tell Salvatore cares and has passion for what he does just by looking at his work.
https://github.com/antirez/redis/tree/unstable/src
In A quick look at the Redis source codeRedis - https://github.com/antirez/redis
Edit: GitHub actually has a good list of trending repositories that you can filter by language. Most C projects seem to be libraries, but you might be able to glean something interesting - https://github.com/trending?l=c&since=monthly
In The Architecture of Open Source ApplicationsRedis doesn't compress contents of lists (or hashes or zsets) in a "ziplist", it packs them in a concise manner that omits structure overhead.
Source: the source code of Redis itself https://github.com/antirez/redis/blob/unstable/src/ziplist.c , Redis documentation: http://redis.io/topics/memory-optimization , and/or my book: http://bitly.com/redis-in-action .
In Save Redis memory with large list compressionThe idea behind Dockerfiles is to allow a source repository to be built and packaged automatically, to the exact specification of the upstream developer, regardless of his/her choice of development tools, distro or language.
Source repo comes in, container comes out. No other exchange of information necessary. The only dependencies left are 1) the hardware architecture, 2) the kernel and 3) the docker runtime (which is itself a 5MB static binary).
This makes things like this potentially possible:
$ docker run git://github.com/antirez/redis
Voila, you are running Redis - built and configured to the specifications of Salvatore himself.
In Create Dockerfiles for easily buildable Docker containersIf the values you are storing are integers, you should also look at your zset-max-ziplist-entries config setting. I've been able to shrink a 30GB Redis memory footprint to just under 3GB. The caveat is that all search operations in ziplists are sequential (since it uses variable-length strings and integers), but oftentimes scanning a short array is as fast or faster than hashing or locating an entry in a skiplist. There is more details about this here http://redis.io/topics/memory-optimization, and I've submitted a patch to Redis that makes it even more efficient (https://github.com/antirez/redis/issues/469).
In From 1.5 GB to 50 MB: The Story of my Redis DatabaseYou will get said timer support in Redis 2.8 with the ability to subscribe to keyspace events, which includes keys expiring (with millisecond resolution). https://github.com/antirez/redis/issues/594
psubscribe __keyevent@0__:expired cron_*
psetex cron_run-me-in-1s 1000 0
In Introducing Chronos: A Replacement for CronRedis has an implementation of incrementally rehashing hash table in "dict.c" file. Very simple to understand code.
https://github.com/antirez/redis/blob/unstable/src/dict.h
https://github.com/antirez/redis/blob/unstable/src/dict.c
As you can see no rocket science there.
In C++ containers that save memory and time