{"slug": "redis", "name": "Redis", "category": "databases", "category_name": "Databases", "description": "In-memory key-value data store used as a cache, message broker, and database.", "recommenders": 22, "commenters": 47, "warners": 4, "score": 21.68, "rising": -1.89, "first": "2025-11-17", "latest": "2026-10-30", "why": "Liked as a fast cache that is quick to set up and rarely needs maintenance, and as a backend for job queues.", "why_is_quote": false, "has_verdict": true, "sentiment": {"recommend": 22, "neutral": 19, "compare": 2, "warn": 4}, "spark": [0, 1, 4, 1, 1, 1, 2, 5, 3, 2, 1, 1], "listed": true, "loved": ["Caching speed", "Easy to operate"], "caveat": "License changes", "short_quote": "it's trivial to set up and it ~never crashes or requires maintenance.", "icon": true, "domain": null, "github_repo": null, "official_url": "https://redis.io", "pricing": "open source", "aliases": ["Redis"], "verdict": [{"text": "Liked as a fast cache", "cites": [{"id": 804806737, "item_id": 50300421, "url": "https://news.ycombinator.com/item?id=50300421", "by": "imchuncai", "date": "2026-10-30", "stance": "recommend", "quote": "redis is 7 times better", "excerpt": "Performance poor as a cache, redis is 7 times better: https://github.com/kividbio/kividb/issues/202", "context": "", "use_case": "cache", "switched_from": "", "story": "Show HN: KiviDB, a faster Redis-compatible memory database and vector cache"}, {"id": 778926832, "item_id": 48682927, "url": "https://news.ycombinator.com/item?id=48682927", "by": "fastball", "date": "2026-06-25", "stance": "recommend", "quote": "it is much faster than your db query if cache is set, there is some amount of robustness if your db is temporarily unavailable", "excerpt": "Hot paths are basically never entirely comprised of your db query directly \u2013 they are part of some business logic contained in a backend service. So: you identify that \"this API route is called a lot, but doesn't always need the exact data at time of call\", and then you do this: cached_val = redis.get(MY_CACHED_KEY); if (cached_val) return cached_val; db_val = pg.select(...); redis.set(MY_CACHED_KEY, db_val, ttl=60s)", "context": "", "use_case": "caching hot API routes", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 762673906, "item_id": 47667119, "url": "https://news.ycombinator.com/item?id=47667119", "by": "roscas", "date": "2026-04-06", "stance": "recommend", "quote": "Redis (or valkey.io) is also amazing and very fast.", "excerpt": "Oh what a huge article and a good read. Thank you. Ok, let's go. Why people use Kafka? Because you can throw lava at it and it will eat it. RabbitMQ is also very good, don't have production experience on it, so I leave it for a specialist. Redis (or valkey.io) is also amazing and very fast. But for a tram system or any system that needs persistent record for a period of time, I use a Kafka cluster with minimum of 3 s", "context": "", "use_case": "", "switched_from": "", "story": "I Replaced Kafka, Redis, and RabbitMQ with One Tool \u2013 A Deep Dive into NATS"}]}, {"text": " that is quick to set up and rarely needs maintenance,", "cites": [{"id": 780905537, "item_id": 48806596, "url": "https://news.ycombinator.com/item?id=48806596", "by": "dpc10", "date": "2026-07-06", "stance": "recommend", "quote": "it's trivial to set up and it ~never crashes or requires maintenance.", "excerpt": "I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of \"use Postgres for everything\" articles and they imply a difficulty in running other software that I just don't see. I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange g", "context": "", "use_case": "fast key-value storage", "switched_from": "", "story": "You probably don't need another database"}, {"id": 778246577, "item_id": 48640411, "url": "https://news.ycombinator.com/item?id=48640411", "by": "tempest_", "date": "2026-06-22", "stance": "recommend", "quote": "For many use cases I have not had to think more than 30s to setup redis.", "excerpt": "> Mature ops would be tracking cache hit ratios right? Sure, and sentry integrates well with redis in python which is what I use primarily with redis. I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case. Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis. (al", "context": "Python developer", "use_case": "caching", "switched_from": "", "story": "In Praise of Memcached"}, {"id": 781431425, "item_id": 48839464, "url": "https://news.ycombinator.com/item?id=48839464", "by": "lofties", "date": "2026-07-08", "stance": "recommend", "quote": "Well, that and Redis. No complaints ever.", "excerpt": "Wow, it's using NATS! I used NATS extensively 10+ years ago, and I'm happy to hear it's still around. Our infrastructure had hiccups across our fleet of machines, but one part that always remained up and running without complaining on some dinky machine was NATS. Well, that and Redis. No complaints ever.", "context": "used it extensively 10+ years ago", "use_case": "", "switched_from": "", "story": "Chatto is now Open Source"}]}, {"text": " and as a backend for job queues.", "cites": [{"id": 784694018, "item_id": 49043376, "url": "https://news.ycombinator.com/item?id=49043376", "by": "vhiremath4", "date": "2026-07-24", "stance": "recommend", "quote": "it's always better to use something like SQS, Redis queues, etc.", "excerpt": "I once was the CTO of a company that serviced about 100k requests per day across all our services. We grew to millions and eventually 10's of millions, but, somewhere along the way, an engineer on our team decided he wanted to build a queue off LISTEN/NOTIFY semantics in order to take advantage of strong consistency with the rest of our data model, which seemed reasonable given LISTEN/NOTIFY is not that hard to under", "context": "former CTO", "use_case": "job queue", "switched_from": "", "story": "Postgres LISTEN/NOTIFY actually scales"}, {"id": 745826832, "item_id": 46614177, "url": "https://news.ycombinator.com/item?id=46614177", "by": "reena_signalhq", "date": "2026-01-14", "stance": "recommend", "quote": "I've been using Redis for background jobs for years and it's been solid", "excerpt": "Interesting migration story! I've been using Redis for background jobs for years and it's been solid, but the operational overhead is real. Curious about your experience with SolidQueue's reliability - have you run into any edge cases or issues with job retries/failures? Redis has been battle-tested for so long that switching always feels risky. Would love to hear more about your production experience after a few mon", "context": "", "use_case": "background jobs", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}, {"id": 786973988, "item_id": 49185874, "url": "https://news.ycombinator.com/item?id=49185874", "by": "Gayithri2026", "date": "2026-08-05", "stance": "recommend", "quote": "Celery/Redis for async ingestion returning an immediate job ID", "excerpt": "Location: San Jose, CA (SF Bay Area) Remote: Yes Willing to relocate: No Technologies: Python, FastAPI, PostgreSQL/pgvector, RAG, LangChain, PydanticAI, Celery, Redis, Docker, AWS, Langfuse, Java, Spring Boot R\u00e9sum\u00e9/CV: https://github.com/Gayithri606/resume/blob/main/GayithriPonnapalli-Resume.pdf Email: gayithri@pojoai.com AI engineer building RAG chatbots and AI-driven workflow automation. Five years of production J", "context": "AI engineer building RAG chatbots", "use_case": "async ingestion broker", "switched_from": "", "story": "Ask HN: Who wants to be hired? (August 2026)"}]}, {"text": " The most common complaint is its license changes, which pushed some commenters to Valkey,", "cites": [{"id": 800546865, "item_id": 50034179, "url": "https://news.ycombinator.com/item?id=50034179", "by": "Cort3z", "date": "2026-10-10", "stance": "warn", "quote": "So much software I love keeps doing this. redis, docker, now bitwarden.", "excerpt": "I hate this. So much software I love keeps doing this. redis, docker, now bitwarden. I was so happy with bitwarden. Been a premium subscriber for many years. I have helped convert many people, including whole companies, to use this. Now they are doing us such a disservice. We need a completely free, no-nonsence, alternative. I wonder if it is possible to do a ipfs/torrent version without a central authority to perman", "context": "", "use_case": "", "switched_from": "", "story": "Bitwarden Dual License Model"}, {"id": 747654180, "item_id": 46728386, "url": "https://news.ycombinator.com/item?id=46728386", "by": "maxpert", "date": "2026-01-22", "stance": "warn", "quote": "we have seen the Redis train-wreck in slow-mo", "excerpt": "Disclaimer: I am author of Marmot https://github.com/maxpert/marmot so I will sound extremely bias. I have been asked multiple times on why I chose SQLite and not Turso. I've always responded people that I don't trust an open-source project once it's backed by a VC firm. I've moved away from Redis to Val-Key for same reason, and we have seen the Redis train-wreck in slow-mo. I hope at no point in future Turso ever en", "context": "", "use_case": "key-value store", "switched_from": "", "story": "Turso is an in-process SQL database, compatible with SQLite"}, {"id": 774609761, "item_id": 48413110, "url": "https://news.ycombinator.com/item?id=48413110", "by": "jillesvangurp", "date": "2026-06-05", "stance": "neutral", "quote": "The feature set was fine five years ago and I don't think we're using anything in Valkey that wouldn't work in Redis.", "excerpt": "We switched to Valkey two years ago. I haven't really looked back. I think both projects have done a lot of nice stuff since the split but it's not really impacting anything I use. The feature set was fine five years ago and I don't think we're using anything in Valkey that wouldn't work in Redis. There are probably a lot of projects that never switched over because they had no real need. But most of the cloud provid", "context": "", "use_case": "in-memory data store", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}]}, {"text": " and several warn against using it as the primary store for relational or critical data.", "cites": [{"id": 790403264, "item_id": 49400204, "url": "https://news.ycombinator.com/item?id=49400204", "by": "spoiler", "date": "2026-08-22", "stance": "warn", "quote": "He insisted we use Redis for a project with a lot of relational data. We ended up building a mini relational database on top of redis.", "excerpt": "I think it honestly not even a signal of how good anymore. It's become noise in my experience.. I've worked with an absolute leetcode beast and had a masters in CS. He insisted we use Redis for a project with a lot of relational data. We ended up building a mini relational database on top of redis. Whatever you're imagining about the dev experience, it was worse. He was a lead/senior engineer at the company. Turns ou", "context": "", "use_case": "relational data storage", "switched_from": "", "story": "A formal degree and algorithmic problem-solving is the answer. Always has been"}, {"id": 774638288, "item_id": 48414893, "url": "https://news.ycombinator.com/item?id=48414893", "by": "tossandthrow", "date": "2026-06-05", "stance": "recommend", "quote": "We use redis as infrastructure. To route events and as a cache.", "excerpt": "Obviously these are application decisions. You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it. We use redis as infrastructure. To route events and as a cache. For us redis could go down and we would merely see a degradation of our service with no data loss. I recommend using redis like that. And then use a database that supports transactions for real", "context": "", "use_case": "event routing and cache", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}, {"id": 745851424, "item_id": 46615714, "url": "https://news.ycombinator.com/item?id=46615714", "by": "skywhopper", "date": "2026-01-14", "stance": "recommend", "quote": "For caching, though, I wouldn\u2019t drop Redis so fast.", "excerpt": "Redis is fundamentally the wrong storage system for a job queue when you have an RDBMS handy. This is not new information. You still might want to split the job queue onto its own DB server when things start getting busy, though. For caching, though, I wouldn\u2019t drop Redis so fast. As a in-memory cache, the ops overhead of running Redis is a lot lower. You can even ignore HA for most use cases. Source: I helped design", "context": "helped design Rails SaaS caching architecture", "use_case": "caching", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}]}], "praise": [{"label": "Caching speed", "summary": "Commenters call it very fast and much quicker than querying the database for cached values.", "quotes": [{"id": 778926832, "item_id": 48682927, "url": "https://news.ycombinator.com/item?id=48682927", "by": "fastball", "date": "2026-06-25", "stance": "recommend", "quote": "it is much faster than your db query if cache is set, there is some amount of robustness if your db is temporarily unavailable", "excerpt": "Hot paths are basically never entirely comprised of your db query directly \u2013 they are part of some business logic contained in a backend service. So: you identify that \"this API route is called a lot, but doesn't always need the exact data at time of call\", and then you do this: cached_val = redis.get(MY_CACHED_KEY); if (cached_val) return cached_val; db_val = pg.select(...); redis.set(MY_CACHED_KEY, db_val, ttl=60s)", "context": "", "use_case": "caching hot API routes", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 804806737, "item_id": 50300421, "url": "https://news.ycombinator.com/item?id=50300421", "by": "imchuncai", "date": "2026-10-30", "stance": "recommend", "quote": "redis is 7 times better", "excerpt": "Performance poor as a cache, redis is 7 times better: https://github.com/kividbio/kividb/issues/202", "context": "", "use_case": "cache", "switched_from": "", "story": "Show HN: KiviDB, a faster Redis-compatible memory database and vector cache"}, {"id": 762673906, "item_id": 47667119, "url": "https://news.ycombinator.com/item?id=47667119", "by": "roscas", "date": "2026-04-06", "stance": "recommend", "quote": "Redis (or valkey.io) is also amazing and very fast.", "excerpt": "Oh what a huge article and a good read. Thank you. Ok, let's go. Why people use Kafka? Because you can throw lava at it and it will eat it. RabbitMQ is also very good, don't have production experience on it, so I leave it for a specialist. Redis (or valkey.io) is also amazing and very fast. But for a tram system or any system that needs persistent record for a period of time, I use a Kafka cluster with minimum of 3 s", "context": "", "use_case": "", "switched_from": "", "story": "I Replaced Kafka, Redis, and RabbitMQ with One Tool \u2013 A Deep Dive into NATS"}]}, {"label": "Easy to operate", "summary": "Commenters say it is trivial to set up, rarely crashes, and has low ops overhead as a cache.", "quotes": [{"id": 780905537, "item_id": 48806596, "url": "https://news.ycombinator.com/item?id=48806596", "by": "dpc10", "date": "2026-07-06", "stance": "recommend", "quote": "it's trivial to set up and it ~never crashes or requires maintenance.", "excerpt": "I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of \"use Postgres for everything\" articles and they imply a difficulty in running other software that I just don't see. I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange g", "context": "", "use_case": "fast key-value storage", "switched_from": "", "story": "You probably don't need another database"}, {"id": 778246577, "item_id": 48640411, "url": "https://news.ycombinator.com/item?id=48640411", "by": "tempest_", "date": "2026-06-22", "stance": "recommend", "quote": "For many use cases I have not had to think more than 30s to setup redis.", "excerpt": "> Mature ops would be tracking cache hit ratios right? Sure, and sentry integrates well with redis in python which is what I use primarily with redis. I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case. Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis. (al", "context": "Python developer", "use_case": "caching", "switched_from": "", "story": "In Praise of Memcached"}, {"id": 745851424, "item_id": 46615714, "url": "https://news.ycombinator.com/item?id=46615714", "by": "skywhopper", "date": "2026-01-14", "stance": "recommend", "quote": "For caching, though, I wouldn\u2019t drop Redis so fast.", "excerpt": "Redis is fundamentally the wrong storage system for a job queue when you have an RDBMS handy. This is not new information. You still might want to split the job queue onto its own DB server when things start getting busy, though. For caching, though, I wouldn\u2019t drop Redis so fast. As a in-memory cache, the ops overhead of running Redis is a lot lower. You can even ignore HA for most use cases. Source: I helped design", "context": "helped design Rails SaaS caching architecture", "use_case": "caching", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}]}, {"label": "Job queues", "summary": "Commenters use it as a queue backend, often with Celery, and call it solid for background jobs.", "quotes": [{"id": 784694018, "item_id": 49043376, "url": "https://news.ycombinator.com/item?id=49043376", "by": "vhiremath4", "date": "2026-07-24", "stance": "recommend", "quote": "it's always better to use something like SQS, Redis queues, etc.", "excerpt": "I once was the CTO of a company that serviced about 100k requests per day across all our services. We grew to millions and eventually 10's of millions, but, somewhere along the way, an engineer on our team decided he wanted to build a queue off LISTEN/NOTIFY semantics in order to take advantage of strong consistency with the rest of our data model, which seemed reasonable given LISTEN/NOTIFY is not that hard to under", "context": "former CTO", "use_case": "job queue", "switched_from": "", "story": "Postgres LISTEN/NOTIFY actually scales"}, {"id": 745826832, "item_id": 46614177, "url": "https://news.ycombinator.com/item?id=46614177", "by": "reena_signalhq", "date": "2026-01-14", "stance": "recommend", "quote": "I've been using Redis for background jobs for years and it's been solid", "excerpt": "Interesting migration story! I've been using Redis for background jobs for years and it's been solid, but the operational overhead is real. Curious about your experience with SolidQueue's reliability - have you run into any edge cases or issues with job retries/failures? Redis has been battle-tested for so long that switching always feels risky. Would love to hear more about your production experience after a few mon", "context": "", "use_case": "background jobs", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}, {"id": 748545124, "item_id": 46784070, "url": "https://news.ycombinator.com/item?id=46784070", "by": "robinbaertschi", "date": "2026-01-27", "stance": "neutral", "quote": "I use Celery with Redis", "excerpt": "Hi HN, I\u2019m the creator of TypoGuard. I built this specialized engine to help protect brands against typosquatting and phishing domains before they are used in active attacks. The Core Logic: Unlike basic permutation tools, TypoGuard uses a multi-factor risk scoring system (High Risk >= 8 points). The scoring is based on: Domain Metadata: Real-time WHOIS age (domains \u2264 30 days are flagged), MX record presence, and SSL", "context": "", "use_case": "task queue broker", "switched_from": "", "story": "Show HN: TypoGuard \u2013 A typosquatting monitoring engine with automated reporting"}]}, {"label": "Reliability", "summary": "Commenters report it staying up for years without complaints.", "quotes": [{"id": 781431425, "item_id": 48839464, "url": "https://news.ycombinator.com/item?id=48839464", "by": "lofties", "date": "2026-07-08", "stance": "recommend", "quote": "Well, that and Redis. No complaints ever.", "excerpt": "Wow, it's using NATS! I used NATS extensively 10+ years ago, and I'm happy to hear it's still around. Our infrastructure had hiccups across our fleet of machines, but one part that always remained up and running without complaining on some dinky machine was NATS. Well, that and Redis. No complaints ever.", "context": "used it extensively 10+ years ago", "use_case": "", "switched_from": "", "story": "Chatto is now Open Source"}, {"id": 745826832, "item_id": 46614177, "url": "https://news.ycombinator.com/item?id=46614177", "by": "reena_signalhq", "date": "2026-01-14", "stance": "recommend", "quote": "I've been using Redis for background jobs for years and it's been solid", "excerpt": "Interesting migration story! I've been using Redis for background jobs for years and it's been solid, but the operational overhead is real. Curious about your experience with SolidQueue's reliability - have you run into any edge cases or issues with job retries/failures? Redis has been battle-tested for so long that switching always feels risky. Would love to hear more about your production experience after a few mon", "context": "", "use_case": "background jobs", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}]}, {"label": "Data structures", "summary": "Valued as a versatile tool for shared data structures such as sets, counters and locks.", "quotes": [{"id": 774580576, "item_id": 48411286, "url": "https://news.ycombinator.com/item?id=48411286", "by": "9dev", "date": "2026-06-05", "stance": "recommend", "quote": "While I love Redis as a versatile tool for external data structures", "excerpt": "While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO: One, it would be cool to be able to embed it, similar to sqlite, directly into applications. Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two en", "context": "", "use_case": "external data structures", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}, {"id": 742019058, "item_id": 46376191, "url": "https://news.ycombinator.com/item?id=46376191", "by": "1103938364", "date": "2025-12-24", "stance": "recommend", "quote": "L1: Redis Hot Pool (Sets) for O(1) matching of currently active volunteers.", "excerpt": "Hello HN! I'm the author of SoakUpTheSun. This is an open-source visual assistance platform I built to connect visually impaired users with volunteers via real-time video (similar to \"Be My Eyes\", but open-source). I built this primarily to learn how to handle high-concurrency scenarios and heterogeneous microservices. Key technical implementation details: Custom SFU in Go: Instead of using standard media servers, I ", "context": "", "use_case": "hot pool volunteer matching", "switched_from": "", "story": "Show HN: Opensource\"BeMyEyes\"alternative(Java/Go/Python)built as a learning pjet"}, {"id": 748214608, "item_id": 46763413, "url": "https://news.ycombinator.com/item?id=46763413", "by": "storystarling", "date": "2026-01-26", "stance": "recommend", "quote": "treating every agent action as a transaction against a Redis counter", "excerpt": "I built a similar internal ledger for my print-on-demand setup because the image generation costs were eating all the margin. The architecture that finally worked was treating every agent action as a transaction against a Redis counter. We use Celery for the heavy lifting, but the worker has to acquire a lock and deduct credits atomically from Redis before it can even call the external provider. If the balance hits z", "context": "runs a print-on-demand business", "use_case": "atomic credit counters", "switched_from": "", "story": "How are people handling paid external APIs for autonomous agents?"}]}, {"label": "Pairs with Postgres", "summary": "Commenters say Redis alongside PostgreSQL covers many needs.", "quotes": [{"id": 778740019, "item_id": 48671251, "url": "https://news.ycombinator.com/item?id=48671251", "by": "Imustaskforhelp", "date": "2026-06-25", "stance": "recommend", "quote": "something like clickhouse or redis combined with postgresql might be more than enough for many things", "excerpt": "I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc. which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more ", "context": "", "use_case": "caching alongside PostgreSQL", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 758442258, "item_id": 47402641, "url": "https://news.ycombinator.com/item?id=47402641", "by": "bodash", "date": "2026-03-16", "stance": "recommend", "quote": "Go + HTMX + PostgreSQL + Redis can go a long mile", "excerpt": "Personally, I think Go + HTMX + PostgreSQL + Redis can go a long mile, but I could be missing hindsights", "context": "", "use_case": "rebuilding HN", "switched_from": "", "story": "Ask HN: What tech stack would you pick to rebuild HN today?"}, {"id": 774638288, "item_id": 48414893, "url": "https://news.ycombinator.com/item?id=48414893", "by": "tossandthrow", "date": "2026-06-05", "stance": "recommend", "quote": "We use redis as infrastructure. To route events and as a cache.", "excerpt": "Obviously these are application decisions. You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it. We use redis as infrastructure. To route events and as a cache. For us redis could go down and we would merely see a degradation of our service with no data loss. I recommend using redis like that. And then use a database that supports transactions for real", "context": "", "use_case": "event routing and cache", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}]}], "caveats": [{"label": "License changes", "summary": "Its license changes eroded trust and led some commenters to move to Valkey.", "quotes": [{"id": 747654180, "item_id": 46728386, "url": "https://news.ycombinator.com/item?id=46728386", "by": "maxpert", "date": "2026-01-22", "stance": "warn", "quote": "we have seen the Redis train-wreck in slow-mo", "excerpt": "Disclaimer: I am author of Marmot https://github.com/maxpert/marmot so I will sound extremely bias. I have been asked multiple times on why I chose SQLite and not Turso. I've always responded people that I don't trust an open-source project once it's backed by a VC firm. I've moved away from Redis to Val-Key for same reason, and we have seen the Redis train-wreck in slow-mo. I hope at no point in future Turso ever en", "context": "", "use_case": "key-value store", "switched_from": "", "story": "Turso is an in-process SQL database, compatible with SQLite"}, {"id": 800546865, "item_id": 50034179, "url": "https://news.ycombinator.com/item?id=50034179", "by": "Cort3z", "date": "2026-10-10", "stance": "warn", "quote": "So much software I love keeps doing this. redis, docker, now bitwarden.", "excerpt": "I hate this. So much software I love keeps doing this. redis, docker, now bitwarden. I was so happy with bitwarden. Been a premium subscriber for many years. I have helped convert many people, including whole companies, to use this. Now they are doing us such a disservice. We need a completely free, no-nonsence, alternative. I wonder if it is possible to do a ipfs/torrent version without a central authority to perman", "context": "", "use_case": "", "switched_from": "", "story": "Bitwarden Dual License Model"}, {"id": 774609761, "item_id": 48413110, "url": "https://news.ycombinator.com/item?id=48413110", "by": "jillesvangurp", "date": "2026-06-05", "stance": "neutral", "quote": "The feature set was fine five years ago and I don't think we're using anything in Valkey that wouldn't work in Redis.", "excerpt": "We switched to Valkey two years ago. I haven't really looked back. I think both projects have done a lot of nice stuff since the split but it's not really impacting anything I use. The feature set was fine five years ago and I don't think we're using anything in Valkey that wouldn't work in Redis. There are probably a lot of projects that never switched over because they had no real need. But most of the cloud provid", "context": "", "use_case": "in-memory data store", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}]}, {"label": "Not a primary store", "summary": "Commenters warn against using it for relational data or as the only store for important data.", "quotes": [{"id": 790403264, "item_id": 49400204, "url": "https://news.ycombinator.com/item?id=49400204", "by": "spoiler", "date": "2026-08-22", "stance": "warn", "quote": "He insisted we use Redis for a project with a lot of relational data. We ended up building a mini relational database on top of redis.", "excerpt": "I think it honestly not even a signal of how good anymore. It's become noise in my experience.. I've worked with an absolute leetcode beast and had a masters in CS. He insisted we use Redis for a project with a lot of relational data. We ended up building a mini relational database on top of redis. Whatever you're imagining about the dev experience, it was worse. He was a lead/senior engineer at the company. Turns ou", "context": "", "use_case": "relational data storage", "switched_from": "", "story": "A formal degree and algorithmic problem-solving is the answer. Always has been"}, {"id": 774638288, "item_id": 48414893, "url": "https://news.ycombinator.com/item?id=48414893", "by": "tossandthrow", "date": "2026-06-05", "stance": "recommend", "quote": "We use redis as infrastructure. To route events and as a cache.", "excerpt": "Obviously these are application decisions. You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it. We use redis as infrastructure. To route events and as a cache. For us redis could go down and we would merely see a degradation of our service with no data loss. I recommend using redis like that. And then use a database that supports transactions for real", "context": "", "use_case": "event routing and cache", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}, {"id": 745851424, "item_id": 46615714, "url": "https://news.ycombinator.com/item?id=46615714", "by": "skywhopper", "date": "2026-01-14", "stance": "recommend", "quote": "For caching, though, I wouldn\u2019t drop Redis so fast.", "excerpt": "Redis is fundamentally the wrong storage system for a job queue when you have an RDBMS handy. This is not new information. You still might want to split the job queue onto its own DB server when things start getting busy, though. For caching, though, I wouldn\u2019t drop Redis so fast. As a in-memory cache, the ops overhead of running Redis is a lot lower. You can even ignore HA for most use cases. Source: I helped design", "context": "helped design Rails SaaS caching architecture", "use_case": "caching", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}]}, {"label": "Complex HA", "summary": "High availability is described as overly complicated, and it cannot be embedded like SQLite.", "quotes": [{"id": 774580576, "item_id": 48411286, "url": "https://news.ycombinator.com/item?id=48411286", "by": "9dev", "date": "2026-06-05", "stance": "recommend", "quote": "While I love Redis as a versatile tool for external data structures", "excerpt": "While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO: One, it would be cool to be able to embed it, similar to sqlite, directly into applications. Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two en", "context": "", "use_case": "external data structures", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}]}, {"label": "Client libraries", "summary": "Client libraries are often lacking, with redis-py's async client cited as an example.", "quotes": [{"id": 773241872, "item_id": 48327617, "url": "https://news.ycombinator.com/item?id=48327617", "by": "22graeme", "date": "2026-05-29", "stance": "recommend", "quote": "Redis is great, but the client libraries are often lacking.", "excerpt": "Redis is great, but the client libraries are often lacking. redis-py's async client is a typical example, with horrible typing and a design where async was bolted on as an afterthought. coredis is a fork of the old \"aredis\" client that has been recently rewritten on anyio (making it the only client to support Trio). It's designed with async in mind and uses smart hybrid command routing: multiplexing when possible, co", "context": "", "use_case": "", "switched_from": "", "story": "Redis-py sucks. It's time for something better"}]}, {"label": "Memcached comparison", "summary": "One commenter says memcached is much faster for simple key-value caching.", "quotes": [{"id": 778299185, "item_id": 48643699, "url": "https://news.ycombinator.com/item?id=48643699", "by": "jitl", "date": "2026-06-23", "stance": "neutral", "quote": "at notion we use redis for a lot of things, but actual caching we leave to memcached", "excerpt": "memcached is about a bazillion times faster than redis at doing the simple KV cache job. it\u2019s got threads. it\u2019s highly optimized to do its one job super well, where redis is more a arbitrary shared Python heap kinda thing with all the data structures and single thread and whatnot. at notion we use redis for a lot of things, but actual caching we leave to memcached", "context": "works at Notion", "use_case": "non-caching data structures", "switched_from": "", "story": "In Praise of Memcached"}]}, {"label": "Ops overhead", "summary": "Running it as a separate service adds operational overhead and cost.", "quotes": [{"id": 745826832, "item_id": 46614177, "url": "https://news.ycombinator.com/item?id=46614177", "by": "reena_signalhq", "date": "2026-01-14", "stance": "recommend", "quote": "I've been using Redis for background jobs for years and it's been solid", "excerpt": "Interesting migration story! I've been using Redis for background jobs for years and it's been solid, but the operational overhead is real. Curious about your experience with SolidQueue's reliability - have you run into any edge cases or issues with job retries/failures? Redis has been battle-tested for so long that switching always feels risky. Would love to hear more about your production experience after a few mon", "context": "", "use_case": "background jobs", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}, {"id": 780913089, "item_id": 48807068, "url": "https://news.ycombinator.com/item?id=48807068", "by": "wuliwong", "date": "2026-07-06", "stance": "neutral", "quote": "I have spun up new apps with Redis so many times", "excerpt": "For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc. I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice m", "context": "builds personal projects and MVPs", "use_case": "queues", "switched_from": "", "story": "You probably don't need another database"}]}], "who": [{"by": "zeroroot-ai", "context": "built agent platform for bug bounty work", "url": "https://news.ycombinator.com/item?id=50048471", "date": "2026-10-11"}, {"by": "jdboyd", "context": "runs a $5 VPS", "url": "https://news.ycombinator.com/item?id=49990355", "date": "2026-10-07"}, {"by": "joaokwanza", "context": "senior backend engineer", "url": "https://news.ycombinator.com/item?id=49986323", "date": "2026-10-07"}, {"by": "trueno", "context": "does large scale e-commerce implementations", "url": "https://news.ycombinator.com/item?id=49228512", "date": "2026-08-08"}, {"by": "emanuelecz", "context": "self-taught AI engineer", "url": "https://news.ycombinator.com/item?id=49224408", "date": "2026-08-08"}, {"by": "Gayithri2026", "context": "AI engineer building RAG chatbots", "url": "https://news.ycombinator.com/item?id=49185874", "date": "2026-08-05"}, {"by": "vhiremath4", "context": "former CTO", "url": "https://news.ycombinator.com/item?id=49043376", "date": "2026-07-24"}, {"by": "Sriram1729", "context": "full-stack + AI engineer", "url": "https://news.ycombinator.com/item?id=48915249", "date": "2026-07-14"}, {"by": "lofties", "context": "used it extensively 10+ years ago", "url": "https://news.ycombinator.com/item?id=48839464", "date": "2026-07-08"}, {"by": "wuliwong", "context": "builds personal projects and MVPs", "url": "https://news.ycombinator.com/item?id=48807068", "date": "2026-07-06"}, {"by": "zayd7861", "context": "22 year old solo dev", "url": "https://news.ycombinator.com/item?id=48661295", "date": "2026-06-24"}, {"by": "jitl", "context": "works at Notion", "url": "https://news.ycombinator.com/item?id=48643699", "date": "2026-06-23"}], "tags": ["for caching", "for job queues", "alongside Postgres", "self-hostable"], "use_cases": ["caching", "key-value store", "cache", "shared agent state", "cache for services", "relational data storage"], "compared": [{"slug": "valkey", "name": "Valkey", "co": 8, "switched_from": 0, "switched_to": 6}, {"slug": "postgresql", "name": "PostgreSQL", "co": 17, "switched_from": 0, "switched_to": 1}, {"slug": "celery", "name": "Celery", "co": 5, "switched_from": 0, "switched_to": 0}, {"slug": "claude", "name": "Claude", "co": 4, "switched_from": 0, "switched_to": 0}, {"slug": "sqlite", "name": "SQLite", "co": 4, "switched_from": 0, "switched_to": 0}, {"slug": "solidqueue", "name": "SolidQueue", "co": 2, "switched_from": 0, "switched_to": 1}, {"slug": "next-js", "name": "Next.js", "co": 4, "switched_from": 0, "switched_to": 0}, {"slug": "docker", "name": "Docker", "co": 3, "switched_from": 0, "switched_to": 0}], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49156682", "title": "Ask HN: Who wants to be hired? (August 2026)", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=48805564", "title": "You probably don't need another database", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=48638886", "title": "In Praise of Memcached", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=48382047", "title": "Redis 8.8: New array data structure, rate limiter, performance improvements", "mentions": 3}, {"url": "https://news.ycombinator.com/item?id=48666433", "title": "PostgreSQL Is Enough", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=46614037", "title": "I Love You, Redis, but I'm Leaving You for SolidQueue", "mentions": 2}], "sentiment_by_month": {"2025-11": {"neutral": 1}, "2025-12": {"recommend": 1}, "2026-01": {"recommend": 4, "warn": 1, "neutral": 1}, "2026-02": {"recommend": 1}, "2026-03": {"neutral": 1, "recommend": 1}, "2026-04": {"neutral": 2, "recommend": 1}, "2026-05": {"neutral": 1, "recommend": 2}, "2026-06": {"recommend": 5, "neutral": 5, "compare": 1}, "2026-07": {"recommend": 3, "compare": 1, "neutral": 3}, "2026-08": {"warn": 2, "recommend": 2, "neutral": 1}, "2026-09": {"recommend": 1}, "2026-10": {"neutral": 4, "warn": 1, "recommend": 1}}, "quotes": [{"id": 804806737, "item_id": 50300421, "url": "https://news.ycombinator.com/item?id=50300421", "by": "imchuncai", "date": "2026-10-30", "stance": "recommend", "quote": "redis is 7 times better", "excerpt": "Performance poor as a cache, redis is 7 times better: https://github.com/kividbio/kividb/issues/202", "context": "", "use_case": "cache", "switched_from": "", "story": "Show HN: KiviDB, a faster Redis-compatible memory database and vector cache"}, {"id": 800775536, "item_id": 50048471, "url": "https://news.ycombinator.com/item?id=50048471", "by": "zeroroot-ai", "date": "2026-10-11", "stance": "neutral", "quote": "In my case that state is a knowledge graph and redis.", "excerpt": "I have built toward this for the last year, first for my own bug bounty work, then as a platform. I dont work for a frontier-grade provider though, but have a lot of distributed systems/platform engineering experience. Here is what I have learned: Direct inter-agent communication is tough to scale, tons of messages, agents drift and the cost grows with the square of the agent count. At large scale, agents should almo", "context": "built agent platform for bug bounty work", "use_case": "shared agent state", "switched_from": "", "story": "Ask HN: How do swarms of AI agents work?"}, {"id": 800546865, "item_id": 50034179, "url": "https://news.ycombinator.com/item?id=50034179", "by": "Cort3z", "date": "2026-10-10", "stance": "warn", "quote": "So much software I love keeps doing this. redis, docker, now bitwarden.", "excerpt": "I hate this. So much software I love keeps doing this. redis, docker, now bitwarden. I was so happy with bitwarden. Been a premium subscriber for many years. I have helped convert many people, including whole companies, to use this. Now they are doing us such a disservice. We need a completely free, no-nonsence, alternative. I wonder if it is possible to do a ipfs/torrent version without a central authority to perman", "context": "", "use_case": "", "switched_from": "", "story": "Bitwarden Dual License Model"}, {"id": 799845684, "item_id": 49990355, "url": "https://news.ycombinator.com/item?id=49990355", "by": "jdboyd", "date": "2026-10-07", "stance": "neutral", "quote": "Redis (I forget if that was for filestash or the container registry, but can be configured to be very light weight).", "excerpt": "Here are a few things I do: Host static content behind nginx Run filestash as a partial GoogleDrive replacement (I use it for sharing files with other people, like deliverables), files place on an S3 compatible object store. Run vaultwarder for myself and some family members. Run a container registry service backed by an s3 compatible object store. Run a django web application I wrote for my own use. However, it stor", "context": "runs a $5 VPS", "use_case": "cache for services", "switched_from": "", "story": "Ask HN: What do you run on a $5 VPS that's worth keeping online 24/7?"}, {"id": 799781170, "item_id": 49986323, "url": "https://news.ycombinator.com/item?id=49986323", "by": "joaokwanza", "date": "2026-10-07", "stance": "neutral", "quote": "PostgreSQL, Kafka, Redis", "excerpt": "Location: Luanda, Angola (UTC+1) Remote: Yes Willing to relocate: Yes, with visa sponsorship: Portugal/EU, Canada, UK, Australia; open to a retention agreement on relocation costs Technologies: TypeScript/Node.js, Go, PostgreSQL, Kafka, Redis, AWS (Lambda, API Gateway, DynamoDB, S3, CloudFormation), Next.js/React, LLM agents, MCP R\u00e9sum\u00e9/CV: https://joaokwanza.com/cv.pdf Email: kwanzajoao04@gmail.com Senior backend & ", "context": "senior backend engineer", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (October 2026)"}, {"id": 799164160, "item_id": 49947760, "url": "https://news.ycombinator.com/item?id=49947760", "by": "za_creature", "date": "2026-10-03", "stance": "neutral", "quote": "I used redis multiple times in the past, I have no resentment towards the project or its author(s).", "excerpt": "You are reading into something that isn't there. Grandparent wondered whether he was the only one that mistrusts antirez, parent asked for reasons why one would do that, I provided my own. I used redis multiple times in the past, I have no resentment towards the project or its author(s). That does not mean that either is above criticism, and I know my freedoms quite well thank you very much. Feel free to feel insulte", "context": "", "use_case": "", "switched_from": "", "story": "From the creator of Redis; run LLM locally with ds4"}, {"id": 793050848, "item_id": 49565678, "url": "https://news.ycombinator.com/item?id=49565678", "by": "gandreani", "date": "2026-09-04", "stance": "recommend", "quote": "I used to scoff at redis' single threaded design but it makes sense in a memory bound db.", "excerpt": "Nice! I like learning about databases but got a bit of \"framework fatigue\" when I started reading about all the number of dbs available today (and deciphering marketing from tech notes). This article hooked me with the comparison at the beginning. I used to scoff at redis' single threaded design but it makes sense in a memory bound db. This article is a great example of taking that high-performance approach and desig", "context": "", "use_case": "", "switched_from": "", "story": "Ok, but does it scale?"}, {"id": 790403264, "item_id": 49400204, "url": "https://news.ycombinator.com/item?id=49400204", "by": "spoiler", "date": "2026-08-22", "stance": "warn", "quote": "He insisted we use Redis for a project with a lot of relational data. We ended up building a mini relational database on top of redis.", "excerpt": "I think it honestly not even a signal of how good anymore. It's become noise in my experience.. I've worked with an absolute leetcode beast and had a masters in CS. He insisted we use Redis for a project with a lot of relational data. We ended up building a mini relational database on top of redis. Whatever you're imagining about the dev experience, it was worse. He was a lead/senior engineer at the company. Turns ou", "context": "", "use_case": "relational data storage", "switched_from": "", "story": "A formal degree and algorithmic problem-solving is the answer. Always has been"}, {"id": 787656193, "item_id": 49228512, "url": "https://news.ycombinator.com/item?id=49228512", "by": "trueno", "date": "2026-08-08", "stance": "recommend", "quote": "I really just disagreed with the assessment that redis is not good enough for the job for a reservation system.", "excerpt": "I've done multiple large scale implementations with shopify paired with many flavors of order managmeent systems as well as competing offerings in the space. The only one i haven't touched that i'd like to get my feet wet with is commerce tools. I really just disagreed with the assessment that redis is not good enough for the job for a reservation system. I use sql database all the time, I prefer them. But I'm seeing", "context": "does large scale e-commerce implementations", "use_case": "inventory reservation system", "switched_from": "", "story": "Shopify replaced Redis with MySQL for inventory reservations\u2013and it scaled"}, {"id": 787590533, "item_id": 49224408, "url": "https://news.ycombinator.com/item?id=49224408", "by": "emanuelecz", "date": "2026-08-08", "stance": "neutral", "quote": "Postgres/pgvector, Redis, Celery, Docker", "excerpt": "Location: Gipuzkoa, Spain (CET) Remote: Yes, remote only Willing to relocate: No Technologies: Python, FastAPI, LangGraph, MCP, RAG, Postgres/pgvector, Redis, Celery, Docker, LLM evals, TypeScript, Next.js R\u00e9sum\u00e9/CV: https://www.emanuelecz.dev/emanuele-czofei-cv.pdf Email: emanuelecz06@gmail.com Self-taught AI engineer, two years building, four months at a startup. Strongest at the unglamorous half: retrieval that re", "context": "self-taught AI engineer", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (August 2026)"}, {"id": 786973988, "item_id": 49185874, "url": "https://news.ycombinator.com/item?id=49185874", "by": "Gayithri2026", "date": "2026-08-05", "stance": "recommend", "quote": "Celery/Redis for async ingestion returning an immediate job ID", "excerpt": "Location: San Jose, CA (SF Bay Area) Remote: Yes Willing to relocate: No Technologies: Python, FastAPI, PostgreSQL/pgvector, RAG, LangChain, PydanticAI, Celery, Redis, Docker, AWS, Langfuse, Java, Spring Boot R\u00e9sum\u00e9/CV: https://github.com/Gayithri606/resume/blob/main/GayithriPonnapalli-Resume.pdf Email: gayithri@pojoai.com AI engineer building RAG chatbots and AI-driven workflow automation. Five years of production J", "context": "AI engineer building RAG chatbots", "use_case": "async ingestion broker", "switched_from": "", "story": "Ask HN: Who wants to be hired? (August 2026)"}, {"id": 786628452, "item_id": 49164278, "url": "https://news.ycombinator.com/item?id=49164278", "by": "darkurtpanke", "date": "2026-08-03", "stance": "warn", "quote": "", "excerpt": "Location:Cape town. Remote: Yes. Obviously. I don\u2019t do office culture. I prefer quiet dark room with a 4K monitor and a mechanical keyboard. Willing to relocate: Only if the relocation involves a data center, a hackerspace, or a country with no extradition treaties. Otherwise, no. Technologies:Go, Rust, C, C++., Docker, FreeBSD, and I once fixed a mainframe. Don\u2019t ask how. MongoDB, I\u2019ve written my own key value store", "context": "systems programmer seeking work", "use_case": "key-value store", "switched_from": "", "story": "Ask HN: Who wants to be hired? (August 2026)"}, {"id": 785571345, "item_id": 49098209, "url": "https://news.ycombinator.com/item?id=49098209", "by": "athrv_shrn", "date": "2026-07-29", "stance": "neutral", "quote": "then I use Redis as a Raw storage for all the files and docs", "excerpt": "I am using a system I designed on my own for the 'CRUD' style of thing for renames/deletions you are mentioning. People just hook up a Vector DB and store all the embeddings once and call it a day. I use three databases for the CRUD style system (idk its name, so i will just call it that lol). I use QDrant as the main DB, the one every RAG Pipeline requires, then I use Redis as a Raw storage for all the files and doc", "context": "", "use_case": "raw document storage", "switched_from": "", "story": "Agent and RAG for Obsidian, Need Feedback"}, {"id": 784694018, "item_id": 49043376, "url": "https://news.ycombinator.com/item?id=49043376", "by": "vhiremath4", "date": "2026-07-24", "stance": "recommend", "quote": "it's always better to use something like SQS, Redis queues, etc.", "excerpt": "I once was the CTO of a company that serviced about 100k requests per day across all our services. We grew to millions and eventually 10's of millions, but, somewhere along the way, an engineer on our team decided he wanted to build a queue off LISTEN/NOTIFY semantics in order to take advantage of strong consistency with the rest of our data model, which seemed reasonable given LISTEN/NOTIFY is not that hard to under", "context": "former CTO", "use_case": "job queue", "switched_from": "", "story": "Postgres LISTEN/NOTIFY actually scales"}, {"id": 782643989, "item_id": 48915249, "url": "https://news.ycombinator.com/item?id=48915249", "by": "Sriram1729", "date": "2026-07-14", "stance": "neutral", "quote": "Tech I reach for: TypeScript, Python, React/Next, Node/FastAPI, Postgres + pgvector, Redis, AWS, Claude API and Claude Code.", "excerpt": "Tampa, FL | Remote (US Eastern) | Contract, ~20 hrs/week (evenings + weekends, around a full-time job)I'm a full-stack + AI engineer, 5 years in. Looking for one side engagement I can actually commit to \u2014 nights and weekends, not a flaky \"I'll get to it\" thing. Short version of what I'm good for: give me a problem and I'll hand back something deployed. I do the whole thing \u2014 backend, frontend, the data model, the inf", "context": "full-stack + AI engineer", "use_case": "", "switched_from": "", "story": "Ask HN: Who wants to be hired? (July 2026)"}, {"id": 781431425, "item_id": 48839464, "url": "https://news.ycombinator.com/item?id=48839464", "by": "lofties", "date": "2026-07-08", "stance": "recommend", "quote": "Well, that and Redis. No complaints ever.", "excerpt": "Wow, it's using NATS! I used NATS extensively 10+ years ago, and I'm happy to hear it's still around. Our infrastructure had hiccups across our fleet of machines, but one part that always remained up and running without complaining on some dinky machine was NATS. Well, that and Redis. No complaints ever.", "context": "used it extensively 10+ years ago", "use_case": "", "switched_from": "", "story": "Chatto is now Open Source"}, {"id": 780913089, "item_id": 48807068, "url": "https://news.ycombinator.com/item?id=48807068", "by": "wuliwong", "date": "2026-07-06", "stance": "neutral", "quote": "I have spun up new apps with Redis so many times", "excerpt": "For context, I am mainly talking about my personal projects, ideas I am trying out, MVPs/prototypes for potential new businesses, etc. I have started just using Postgres to back queues. It is simpler (although I have spun up new apps with Redis so many times it is only a small improvement) but more importantly it is cheaper. I really do try a lot of stuff out, so completely removing a infrastructure piece is a nice m", "context": "builds personal projects and MVPs", "use_case": "queues", "switched_from": "", "story": "You probably don't need another database"}, {"id": 780909393, "item_id": 48806837, "url": "https://news.ycombinator.com/item?id=48806837", "by": "JsonDemWitOster", "date": "2026-07-06", "stance": "compare", "quote": "Why wait until, ahem, Postgres is pushed to the limit before you spin up a Redis cluster?", "excerpt": "I'll do you one better: do you really need Postgres and all these extensions when you already have a filesystem? > only after pushing Postgres to its limits, documenting why it was insufficient, and accepting the operational cost of the alternative I love Postgres as a DB but, really, this is ridiculous. No doubt these extensions can do the job well-enough but you might as well invest in learning the right tool for t", "context": "", "use_case": "caching", "switched_from": "", "story": "You probably don't need another database"}, {"id": 780905537, "item_id": 48806596, "url": "https://news.ycombinator.com/item?id=48806596", "by": "dpc10", "date": "2026-07-06", "stance": "recommend", "quote": "it's trivial to set up and it ~never crashes or requires maintenance.", "excerpt": "I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of \"use Postgres for everything\" articles and they imply a difficulty in running other software that I just don't see. I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange g", "context": "", "use_case": "fast key-value storage", "switched_from": "", "story": "You probably don't need another database"}, {"id": 778926832, "item_id": 48682927, "url": "https://news.ycombinator.com/item?id=48682927", "by": "fastball", "date": "2026-06-25", "stance": "recommend", "quote": "it is much faster than your db query if cache is set, there is some amount of robustness if your db is temporarily unavailable", "excerpt": "Hot paths are basically never entirely comprised of your db query directly \u2013 they are part of some business logic contained in a backend service. So: you identify that \"this API route is called a lot, but doesn't always need the exact data at time of call\", and then you do this: cached_val = redis.get(MY_CACHED_KEY); if (cached_val) return cached_val; db_val = pg.select(...); redis.set(MY_CACHED_KEY, db_val, ttl=60s)", "context": "", "use_case": "caching hot API routes", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 778740019, "item_id": 48671251, "url": "https://news.ycombinator.com/item?id=48671251", "by": "Imustaskforhelp", "date": "2026-06-25", "stance": "recommend", "quote": "something like clickhouse or redis combined with postgresql might be more than enough for many things", "excerpt": "I agree, the reason why I had submitted this HN submission post was because I was getting way too deep into the weeds of new databases like surrealdb/tigerbeetle/scylladb etc. which while are an interesting problem to think through because well, it makes me feel smarter knowing these databases. I still felt like postgresql was enough, (at best something like clickhouse or redis combined with postgresql might be more ", "context": "", "use_case": "caching alongside PostgreSQL", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 778580725, "item_id": 48661295, "url": "https://news.ycombinator.com/item?id=48661295", "by": "zayd7861", "date": "2026-06-24", "stance": "neutral", "quote": "Redis deduplication to detect incoming deposits", "excerpt": "Hey HN, I'm a 22 year old solo dev. Over the last 8 months, I wrote 315k lines of code to build an on-chain index fund platform. The stack is FastAPI, React, Celery, Postgres, and Redis running on AWS for $70/month. The core engine works by: Aggregating up to 5,000 user orders every 30 seconds. Routing them across DEX protocols for execution. Settling into a single Gnosis Safe transaction to cut gas costs by 80%. A c", "context": "22 year old solo dev", "use_case": "deduplication, caching", "switched_from": "", "story": "Show HN: Wealtii \u2013 A multi-sig digital asset index fund built by a solo founder"}, {"id": 778364130, "item_id": 48647758, "url": "https://news.ycombinator.com/item?id=48647758", "by": "dyogenez", "date": "2026-06-23", "stance": "compare", "quote": "If I had a smaller cache need and was already using Redis, I'd probably just use that.", "excerpt": "Memcached was a savior for caching when it launched. I love that it was created in 2003 by Brad Fitzpatrick for LiveJournal. Each post on a users feed could have different access restrictions, and this allowed posts (or entire pages) to be cached. I used it with Ruby on Rails for many years. It sped up pages, and just worked. The downside (and upside for speed) is (and always was) that cache was saved in memory not d", "context": "Rails developer", "use_case": "caching", "switched_from": "", "story": "In Praise of Memcached"}, {"id": 778299185, "item_id": 48643699, "url": "https://news.ycombinator.com/item?id=48643699", "by": "jitl", "date": "2026-06-23", "stance": "neutral", "quote": "at notion we use redis for a lot of things, but actual caching we leave to memcached", "excerpt": "memcached is about a bazillion times faster than redis at doing the simple KV cache job. it\u2019s got threads. it\u2019s highly optimized to do its one job super well, where redis is more a arbitrary shared Python heap kinda thing with all the data structures and single thread and whatnot. at notion we use redis for a lot of things, but actual caching we leave to memcached", "context": "works at Notion", "use_case": "non-caching data structures", "switched_from": "", "story": "In Praise of Memcached"}, {"id": 778246577, "item_id": 48640411, "url": "https://news.ycombinator.com/item?id=48640411", "by": "tempest_", "date": "2026-06-22", "stance": "recommend", "quote": "For many use cases I have not had to think more than 30s to setup redis.", "excerpt": "> Mature ops would be tracking cache hit ratios right? Sure, and sentry integrates well with redis in python which is what I use primarily with redis. I don't think memcached is bad, I just think its old and industry has moved to redis because it offers more while covering the previous use case. Calling redis fiddly is a mischaracterization. For many use cases I have not had to think more than 30s to setup redis. (al", "context": "Python developer", "use_case": "caching", "switched_from": "", "story": "In Praise of Memcached"}, {"id": 777163170, "item_id": 48572698, "url": "https://news.ycombinator.com/item?id=48572698", "by": "scurnus", "date": "2026-06-17", "stance": "neutral", "quote": "Redis for caching", "excerpt": "I added the Feed feature to the site to make it more usable from mobile. You can scroll and discover important connections. I used Wikidata as source, ArangoDB as database, Redis for caching, Vue+ Cytoscape.js for frontend. If you are from desktop try Explore mode.", "context": "built HumansMap", "use_case": "caching", "switched_from": "", "story": "HumansMap, a feed of family dynasties and links between orgs. No ads"}, {"id": 776044760, "item_id": 48502797, "url": "https://news.ycombinator.com/item?id=48502797", "by": "denizcakiroglu", "date": "2026-06-12", "stance": "neutral", "quote": "", "excerpt": "Location: Istanbul, T\u00fcrkiye (relocating to Guildford, UK in Sept 2026) Remote: Yes \u2014 full EU overlap; US-East evenings (UTC+3, moving to UTC+0) Willing to relocate: No Technologies: TypeScript, Node.js, NestJS, Fastify, Next.js, React, React Native/Expo, PostgreSQL/Prisma, Redis/BullMQ, Claude API, RAG, tool-calling/MCP, pgvector, Playwright R\u00e9sum\u00e9/CV: https://github.com/denizcakiroglu322 Email: denizcakiroglu322@gma", "context": "full-stack engineer specializing in production LLM systems", "use_case": "queues and caching", "switched_from": "", "story": "Ask HN: Who wants to be hired? (June 2026)"}, {"id": 774638288, "item_id": 48414893, "url": "https://news.ycombinator.com/item?id=48414893", "by": "tossandthrow", "date": "2026-06-05", "stance": "recommend", "quote": "We use redis as infrastructure. To route events and as a cache.", "excerpt": "Obviously these are application decisions. You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it. We use redis as infrastructure. To route events and as a cache. For us redis could go down and we would merely see a degradation of our service with no data loss. I recommend using redis like that. And then use a database that supports transactions for real", "context": "", "use_case": "event routing and cache", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}, {"id": 774609761, "item_id": 48413110, "url": "https://news.ycombinator.com/item?id=48413110", "by": "jillesvangurp", "date": "2026-06-05", "stance": "neutral", "quote": "The feature set was fine five years ago and I don't think we're using anything in Valkey that wouldn't work in Redis.", "excerpt": "We switched to Valkey two years ago. I haven't really looked back. I think both projects have done a lot of nice stuff since the split but it's not really impacting anything I use. The feature set was fine five years ago and I don't think we're using anything in Valkey that wouldn't work in Redis. There are probably a lot of projects that never switched over because they had no real need. But most of the cloud provid", "context": "", "use_case": "in-memory data store", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}, {"id": 774580576, "item_id": 48411286, "url": "https://news.ycombinator.com/item?id=48411286", "by": "9dev", "date": "2026-06-05", "stance": "recommend", "quote": "While I love Redis as a versatile tool for external data structures", "excerpt": "While I love Redis as a versatile tool for external data structures, it's still lacking in two areas IMHO: One, it would be cool to be able to embed it, similar to sqlite, directly into applications. Two, the HA story is so much more complicated than it should be. I totally acknowledge that concurrency and distributed computing is hard, but it should not require reading heaps of documentation and understanding two en", "context": "", "use_case": "external data structures", "switched_from": "", "story": "Redis 8.8: New array data structure, rate limiter, performance improvements"}, {"id": 773241872, "item_id": 48327617, "url": "https://news.ycombinator.com/item?id=48327617", "by": "22graeme", "date": "2026-05-29", "stance": "recommend", "quote": "Redis is great, but the client libraries are often lacking.", "excerpt": "Redis is great, but the client libraries are often lacking. redis-py's async client is a typical example, with horrible typing and a design where async was bolted on as an afterthought. coredis is a fork of the old \"aredis\" client that has been recently rewritten on anyio (making it the only client to support Trio). It's designed with async in mind and uses smart hybrid command routing: multiplexing when possible, co", "context": "", "use_case": "", "switched_from": "", "story": "Redis-py sucks. It's time for something better"}, {"id": 771839475, "item_id": 48239967, "url": "https://news.ycombinator.com/item?id=48239967", "by": "anonu", "date": "2026-05-22", "stance": "recommend", "quote": "if I can write it with redis and python with Claude support in all the boilerplate I'm more likely to go that route", "excerpt": "This used to be aquaq. What happened? I liked this framework when I used it years ago but I've become disillusioned with kdb. I can ask Claude to write specialized rust based tick processing tools so quickly now. So the baseline use case for kdb is eroded away, at least for me. I love kdb as a distributed services framework. But if I can write it with redis and python with Claude support in all the boilerplate I'm mo", "context": "", "use_case": "distributed services", "switched_from": "kdb+", "story": "TorQ: Kdb+ Production Framework"}, {"id": 767609908, "item_id": 47975619, "url": "https://news.ycombinator.com/item?id=47975619", "by": "shepherd-eng", "date": "2026-05-01", "stance": "neutral", "quote": "Postgres & Redis", "excerpt": "Shepherd | ONSITE | San Francisco, CA At Shepherd, we're pursuing the most ambitious technical vision in commercial insurance: fully autonomous underwriting. Shepherd is an AI-native commercial insurance platform transforming how high-hazard industries get covered. The infrastructure behind the AI boom (data centers, semiconductor fabs, renewable energy assets) has to be built and insured, but traditional carriers we", "context": "hiring at Shepherd", "use_case": "cache / data store", "switched_from": "", "story": "Ask HN: Who is hiring? (May 2026)"}, {"id": 766363841, "item_id": 47897740, "url": "https://news.ycombinator.com/item?id=47897740", "by": "preston-kwei", "date": "2026-04-24", "stance": "neutral", "quote": "and caches in Redis", "excerpt": "I agree. I'm trying to sell to enterprise right now and this is a blocker. Basically, my product stores emails in S3, but metadata in Supabase, and caches in Redis. It's all fragmented and super difficult to keep track of. Plus Supabase isn't WORM compliant so it is hard to ensure data doesn't get deleted.", "context": "selling to enterprise", "use_case": "caching", "switched_from": "", "story": "Ask HN: How are you handling data retention across your stack?"}, {"id": 762673906, "item_id": 47667119, "url": "https://news.ycombinator.com/item?id=47667119", "by": "roscas", "date": "2026-04-06", "stance": "recommend", "quote": "Redis (or valkey.io) is also amazing and very fast.", "excerpt": "Oh what a huge article and a good read. Thank you. Ok, let's go. Why people use Kafka? Because you can throw lava at it and it will eat it. RabbitMQ is also very good, don't have production experience on it, so I leave it for a specialist. Redis (or valkey.io) is also amazing and very fast. But for a tram system or any system that needs persistent record for a period of time, I use a Kafka cluster with minimum of 3 s", "context": "", "use_case": "", "switched_from": "", "story": "I Replaced Kafka, Redis, and RabbitMQ with One Tool \u2013 A Deep Dive into NATS"}, {"id": 761630466, "item_id": 47601904, "url": "https://news.ycombinator.com/item?id=47601904", "by": "nastya_geller", "date": "2026-04-01", "stance": "neutral", "quote": "Our tech stack: Go, CockroachDB, RocksDB, WebRTC, Raft, and Redis.", "excerpt": "Stream | Multiple Positions | Amsterdam (NL), Skopje (North Macedonia) | Boulder, CO (US) | Toronto (Canada)) | Remote possible | Full Time | Visa Sponsorship We are consistently hiring backend engineers ranging from Senior level to Staff / Lead / Director / Principal Go engineers. If you have experience with a different tech stack, we offer a 10-week onboarding program to train you in Go, scaling and other key topic", "context": "hiring at Stream", "use_case": "company backend stack", "switched_from": "", "story": "Ask HN: What are you working on? (April 2026)"}, {"id": 758442258, "item_id": 47402641, "url": "https://news.ycombinator.com/item?id=47402641", "by": "bodash", "date": "2026-03-16", "stance": "recommend", "quote": "Go + HTMX + PostgreSQL + Redis can go a long mile", "excerpt": "Personally, I think Go + HTMX + PostgreSQL + Redis can go a long mile, but I could be missing hindsights", "context": "", "use_case": "rebuilding HN", "switched_from": "", "story": "Ask HN: What tech stack would you pick to rebuild HN today?"}, {"id": 757679762, "item_id": 47354985, "url": "https://news.ycombinator.com/item?id=47354985", "by": "agnelnieves", "date": "2026-03-12", "stance": "neutral", "quote": "Redis for real-time presence", "excerpt": "Hey HN, Agnel here, co-founder of Basement Browser. We just launched on Product Hunt! The idea is simple: every webpage you visit already has other people on it. You just can't see them. Basement makes that layer visible when you land on a page, you see a live chat room of people browsing that same URL. No accounts to create on each site, no leaving the page to discuss it on Reddit. On top of that, each user gets a p", "context": "", "use_case": "real-time presence", "switched_from": "", "story": null}, {"id": 754923905, "item_id": 47182744, "url": "https://news.ycombinator.com/item?id=47182744", "by": "kacy", "date": "2026-02-27", "stance": "recommend", "quote": "Redis changed how the industry thinks about caching", "excerpt": "Hi folks, I'm anxious & excited to share Ember: a low-latency, memory-efficient distributed cache written in Rust. I designed it as a drop-in replacement for Redis, but with some modern twists that I've been iterating on and have been on my wishlist. * https://github.com/kacy/ember * https://emberdb.com Here's what makes Ember different IMO: * Native Protobuf storage (so no string serialization overhead and can encod", "context": "15 years working with Redis", "use_case": "caching", "switched_from": "", "story": "Show HN: Ember \u2013 A modern Redis drop-in replacement built in Rust"}, {"id": 748545124, "item_id": 46784070, "url": "https://news.ycombinator.com/item?id=46784070", "by": "robinbaertschi", "date": "2026-01-27", "stance": "neutral", "quote": "I use Celery with Redis", "excerpt": "Hi HN, I\u2019m the creator of TypoGuard. I built this specialized engine to help protect brands against typosquatting and phishing domains before they are used in active attacks. The Core Logic: Unlike basic permutation tools, TypoGuard uses a multi-factor risk scoring system (High Risk >= 8 points). The scoring is based on: Domain Metadata: Real-time WHOIS age (domains \u2264 30 days are flagged), MX record presence, and SSL", "context": "", "use_case": "task queue broker", "switched_from": "", "story": "Show HN: TypoGuard \u2013 A typosquatting monitoring engine with automated reporting"}, {"id": 747654180, "item_id": 46728386, "url": "https://news.ycombinator.com/item?id=46728386", "by": "maxpert", "date": "2026-01-22", "stance": "warn", "quote": "we have seen the Redis train-wreck in slow-mo", "excerpt": "Disclaimer: I am author of Marmot https://github.com/maxpert/marmot so I will sound extremely bias. I have been asked multiple times on why I chose SQLite and not Turso. I've always responded people that I don't trust an open-source project once it's backed by a VC firm. I've moved away from Redis to Val-Key for same reason, and we have seen the Redis train-wreck in slow-mo. I hope at no point in future Turso ever en", "context": "", "use_case": "key-value store", "switched_from": "", "story": "Turso is an in-process SQL database, compatible with SQLite"}, {"id": 745851424, "item_id": 46615714, "url": "https://news.ycombinator.com/item?id=46615714", "by": "skywhopper", "date": "2026-01-14", "stance": "recommend", "quote": "For caching, though, I wouldn\u2019t drop Redis so fast.", "excerpt": "Redis is fundamentally the wrong storage system for a job queue when you have an RDBMS handy. This is not new information. You still might want to split the job queue onto its own DB server when things start getting busy, though. For caching, though, I wouldn\u2019t drop Redis so fast. As a in-memory cache, the ops overhead of running Redis is a lot lower. You can even ignore HA for most use cases. Source: I helped design", "context": "helped design Rails SaaS caching architecture", "use_case": "caching", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}, {"id": 745826832, "item_id": 46614177, "url": "https://news.ycombinator.com/item?id=46614177", "by": "reena_signalhq", "date": "2026-01-14", "stance": "recommend", "quote": "I've been using Redis for background jobs for years and it's been solid", "excerpt": "Interesting migration story! I've been using Redis for background jobs for years and it's been solid, but the operational overhead is real. Curious about your experience with SolidQueue's reliability - have you run into any edge cases or issues with job retries/failures? Redis has been battle-tested for so long that switching always feels risky. Would love to hear more about your production experience after a few mon", "context": "", "use_case": "background jobs", "switched_from": "", "story": "I Love You, Redis, but I'm Leaving You for SolidQueue"}]}