14 ms·

Redis is fast – I'll cache in Postgres

• bart3r 1y ago
  Don't tell DHH
  • Fire-Dragon-DoL 1y ago
    Didn't DHH just release a sqlite-only cache?
    • firecall 1y ago
      Solid Cache, default in Rails 8. Doesn’t require SQLite. Works with other DBs: https://github.com/rails/solid_cache https://github.com/rails/solid_cache
      • Fire-Dragon-DoL 1y ago
        Yeah,so no redis
• joonas 1y ago
  In similar vein, I’d always thought Redka (https://github.com/nalgeon/redka https://github.com/nalgeon/redka) was a neat idea since it gives you access to a subset of the Redis API backed by either SQLite or Postgres
  • notpushkin 1y ago
    Came here to post this. I’m wondering how Redka will compare with Postgres (and Redis) in terms of performance though. Edit: https://antonz.org/redka/#performance https://antonz.org/redka/#performance
• iamcalledrob 1y ago
  This isn't a great test setup. It's testing RTT rather than the peak throughput of Redis. I'd suggest using Redis pipelining -- or better: using the excellent rueidis redis client which performs auto-pipelining. Wouldn't be surprising to see a 10x performance boost. https://github.com/redis/rueidis https://github.com/redis/rueidis
  • oa335 1y ago
    Postgres also supports query pipelining - at it seems like the popular go Postgres client library pgx supports it: https://github.com/jackc/pgx/issues/1113#event-6964024724 https://github.com/jackc/pgx/issues/1113#event-6964024724
  • aaronblohowiak 1y ago
    Even so 35ms+ latency for Redis reads is very very high I’d want to understand what is happening there
  • dizzyVik 1y ago
    Author here. Redis is definitely faster. I was specifically not going for absolute peak performance for either redis or postgres - that would require going down to the wire protocols. The idea was emphasize that there' a "good enough" level of performance. Once you need that sort of speed - sure, there are ways to achieve it.
    • motorest 1y ago
      > The idea was emphasize that there' a "good enough" level of performance. Once you need that sort of speed - sure, there are ways to achieve it. To this I would add that more often than not the extra cost and complexity of a memory cache does not justify shaving off a few hypothetical milliseconds from a fetch. On top of that, some nosql offerings from popular cloud providers already have CRUD operations faster than 20ms.
• arp242 1y ago
  When I last benchmarked Redis vs. PostgreSQL for a simple k/v cache it was about ~1ms for PostgreSQL to fetch a key, and ~0.5ms for Redis with a similar setup as in this post (although I used "value bytea" instead of "value string" – I don't know if it matters, probably not; 1ms was fast enough that I didn't care to test). I didn't measure setting keys or req/sec because for my use case keys were updated infrequently. I generally find ms to be a more useful metric than reqs/sec or latency at full load, as this is not a typical load. Or at least wasn't for my use case. Of course all depends on your use case etc. etc. In some cases throughput does matter. I would encourage everyone to run their own benchmarks suited to their own use case to be sure – should be quick and easy. As I rule I recommend starting with PostgreSQL and using something else only if you're heavily using the cache or you run in to problems. Redis isn't too hard to run, but still just one less service to worry about. Or alternatively, just use a in-memory DB. Not always appropriate of course, but sometimes it is.
  • Maskawanian 1y ago
    When you benchmarked Postgres did you disable WAL for the cache table? That may minimize the difference.
    • arp242 1y ago
      Unlogged table, yes. 1ms is more than fast enough so I didn't bother to look further.
  • xyzzy_plugh 1y ago
    A difference of 0.5ms is negligible with single digit network latency. You would need significant batching to experience the effects of this difference. Of course such sensitive environments are easily imaginable but I wonder why you'd select either in that case.
    • arp242 1y ago
      > A difference of 0.5ms is negligible with single digit network latency Yes, that was my take-away.
• brightball 1y ago
  The big with for Redis is pipelining IMO.
  • brightball 1y ago
    Big “win”
• mehphp 1y ago
  I think you just convinced me to drop redis for my new project. Definitely a premature optimization on my part.
  • throwup238 1y ago
    “Dropping” something from a “new” project is premature optimization? Wherever you go, there you are.
    • danielheath 1y ago
      I read it as dropping something that _had been_ a premature optimisation.
    • qu4z-2 1y ago
      Presumably adding Redis to a new project with no performance issues (yet?) is the premature optimisation.
      • rplnt 1y ago
        If you are optimizng for simplicity it may not be, as the use as a cache is much (much) more straightforward. Also, for a new project, I'd go with in-memory service-level cache as it outperforms both (in any metric) and can be easily replaced once the need arises.
    • mehphp 1y ago
      I was referring to adding redis prematurely
  • MobiusHorizons 1y ago
    “Premature optimization” typically refers to optimizing before profiling. Ie optimizing in places that won’t help. Is redis not improving your latency? Is it adding complexity that isn’t worth it? Why bother removing it?
    • maxbond 1y ago
• sixo 1y ago
  If you use an UNLOGGED table in Postgres as a cache, and your DB restarts, you no longer have a cache. Then your main table gets a huge spike in traffic and likely grinds to a halt.
  • shakna 1y ago
    Cache is not the only solution to the thundering herd.
  • Spivak 1y ago
    Same as the folks who use in-memory Redis. Is there something uniquely bad about Postgres for this situation? If your cache is so performance critical that you can't lose the data then it sounds like you need a (denormalized) database.
  • frollogaston 1y ago
    Cache isn't meant to persist, and something is wrong if you hard depend on it persisting.
  • wielebny 1y ago
    If you need persistence on your Redis, then you're not using is as a cache. You're using it as a key-value store.
  • sgarland 1y ago
    Not quite - if you have a crash / hard restart, the table is truncated. If Postgres gracefully shuts down, the data is retained.
• carterschonwald 1y ago
  This seems to be testing how the software is optimized for low core deployments… how does Postgres perform vary as you add more cores and ram? It’s the sort of software where I’d presume more cores and ram yields better performance. Assuming as always that mature systems software sees more many core perf engineering.
• cortesoft 1y ago
  Having the ability to set a TTL on the cache key is a critical feature of a cache, not something that can be tacked on later. I always find these "don't use redis" posts kind of strange. Redis is so simple to operate at any scale, I don't quite get why it is important to remove it.
  • frollogaston 1y ago
    Yeah, the article was like "I always need a DB anyway" but then sets up an extra cronjob to expire keys, plus more code. I get YAGNI and avoiding deps, but this is really extra stuff to deal with. Maybe Postgres could use a caching feature. Until then, I'm gonna drop in Redis or memcached instead of reinventing the wheel.
    • maxbond 1y ago
      Expiring keys in Postgres with a created_at column and a pg_cron job is very easy (at least, if you're comfortable in Postgres). Redis is world class though of course, and can be deployed turn-key in basically any environment. If you're more comfortable in Redis than Postgres, more power to you. Different choices can be pragmatic to different people. Personally for a greenfield project, my thinking would be that I am paying for Postgres already. So I would want to avoid paying for Redis too. My Postgres database is likely to be underutilized until (and unless) I get any real scale. So adding caching to it is free in terms of dollars.
      • frollogaston 1y ago
        I'm comfy with Postgres though, like I'll center my entire backend around it and do the heavy lifting in SQL (never ORM). It's more that I don't want to depend on a cronjob for something as fundamental as a cache. Usually Postgres costs a lot more than Redis if you're paying for a platform. Like a decent Redis or memcached in Heroku is free. And I don't want to waste precious Postgres connections or risk bogging down the whole DB if there's lots of cache usage, which actually happened last time I tried skipping Redis.
• nvader 1y ago
  I hope you remember to add monitoring for your cache expiry cron job so you can be notified if it ever fails to run due to a code change or configuration change. For example, database credentials might be rolled and if you forget to update the job your primary database could fill up. Perhaps you could have a second cron job that runs to verify that the first one completed. It could look for a last-ran entry. You should put it in the same database, so maybe perhaps you could a key value store like redis for that.
  • monkeyelite 1y ago
    This is more than a few leaps of logic. a bad config of any infrastructure can cause problems
• frollogaston 1y ago
  The values in this test are like 20 bytes, right? Wonder how things compare if they're about 1KB.
  • dizzyVik 1y ago
    Not on my computer right now but I think it's 45 bytes per value
• monkeyelite 1y ago
  In nginx config you can pretty easily cache web pages or API responses. I would also like to know how far that goes. Also does anyone like memcached anymore? When I compared with Redis in the past it appeared more simple.
• hnaccountme 1y ago
  I think there is more performance to be taken from PostgreSQL. Not sure how pgx works internally since I have not used it. There are async functions provided by PostgreSQL client library (libpq). I've used it to process around 2000 queries on a single connection per second on a logged table.
• foobartab 1y ago
  [dead]
• jamesblonde 1y ago
  Why do we promote articles like this that have nice graphs and are well written, when they should get a grade 'F' as an actual benchmark study. The way it is presented, a casual reader would think Postgres is 2/3rds the performance of Redis. Good god. He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server. We need more of an academic, not a hacker, culture for benchmarks.
  • dizzyVik 1y ago
    There's a reason this is on my blog and not a paper in a journal. This isn't supposed to show the absolute speed of either tool, the benchmark is not set up for that. I do state that redis has more performance on the table in the blog post.
    • jamesblonde 1y ago
      [flagged]
      • adamhartenz 1y ago
        That can't have felt great having your tantrum spotlighted by the author.
    • vasco 1y ago
      It's not a paper or a journal but you could at least try to run a decent benchmark. As it is this serves no purpose other than reinforcing whatever point you started with. Didn't even tweak postgres buffers, literally what's the point.
      • dizzyVik 1y ago
        I still end up recommending using postgres though, don't I?
        • pcthrowaway 1y ago
• ezekiel68 1y ago
  > Both postgres and redis are used with the out of the box settings Ugh. I know this gives the illusion of fairness, but it's not how any self-respecting software engineer should approach benchmarks. You have hardware. Perhaps you have virtualized hardware. You tune to the hardware. There simply isn't another way, if you want to be taken seriously. Some will say that in a container-orchestrated environment, tuning goes out the window since "you never know" where the orchestrator will schedule the service but this is bogus. If you've got time to write a basic deployment config for the service on the orchestrator, you've also got time to at least size the memory usage configs for PostgreSQL and/or Redis. It's just that simple. This is the kind of thing that is "hard and tedious" for only about five minutes of LLM query or web search time and then you don't need to revisit it again (unless you decide to change the orchestrator deployment config to give the service more/less resources). It doesn't invite controversy to right-size your persistence services, especially if you are going to publish the results.
  • wewewedxfgdf 1y ago
    Fully agree. Postgres is a power tool usable for many many use cases - if you want performance it must be tuned. If you judge Postgres without tuning it - that's not Postgres being slow, that's the developer being naive.
    • gopalv 1y ago
      > If you judge Postgres without tuning it - that's not Postgres being slow, that's the developer being naive. Didn't OP end by picking Postgres anyway? It's the right answer even for a naive developer, perhaps even more so for a naive one. At the end of the post it even says >> Having an interface for your cache so you can easily switch out the underlying store is definitely something I’ll keep doing
    • lelanthran 1y ago
      He concluded postgresql to be fast enough, so what's the problem? IOW, he judged it fast enough.
  • high_na_euv 1y ago
• wewewedxfgdf 1y ago
  Given there is nothing at all said about the many config options that would contribute to Postgres for this use case, we must assume no configuration has been done. Also, no discussion of indexes or what the data looks like, so we must assume no attention has been paid to their critical factors either. So, another case of lies, damned lies and benchmarks. It seem strange to me people are so willing to post such definitive and poorly researched/argued things - if you're going to take a public position don't you want to be obviously right instead of so easily to discount?
• didip 1y ago
  Is this engagement bait? Sigh... fine, at least I bite the bait here: 1. The use-case is super specific to homelab where consistency doesn't matter. You didn't show us the Redis persistence setup. What is the persistence/durability setting? I bet you'd lose data the one day you forgot and flip the breaker of your homelab. 2. What happened when data is bigger than your 8GB of RAM on Redis? 3. You didn't show us the PG config as well, it is possible to just use all of your RAM as buffer and caching. 4. Postgres has a lot of processes and you give it only 2 CPU? Vanilla Redis is single core so this race is rigged to begin with. The UNLOGGED table even things out a bit. In general, what are you trying to achieve with this "benchmark"? What outcome would you like to learn? Because this "benchmark" will not tell you what you need to know in a production environment. Side note for other HN readers: The UNLOGGED table is actually very nifty trick for speeding up unit tests. Just perform ALTER to UNLOGGED tables inside the PG that's dedicated for CI/CD: ALTER TABLE my_test_table SET UNLOGGED;
  • dizzyVik 1y ago
    1. No persistence for redis. 2. Redis would get OOM killed. 3. The default config coming with the image was used. 4. Yes, I gave it 2 cpus. I wanted to compare how would my http server behave if I used postgres for caching and what the difference would be if I used redis instead. This benchmark is only here to drive the point that sometimes you might not even need a dedicated kv store. Maybe using postgres for this is good enough for your use case. The term production environment might mean many things. Perhaps you're processing hundreds of thousands of requests per second then you'll definitely need a different architecture with HA, scaling, dedicated shared caches etc. However, not many applications reach such a point and often end up using more than necessary to serve their consumers. So I guess I'm just trying to say keep it simple.
    • piniondna 1y ago
      Redis is one of the simplest services I’ve used… we could flip the script and say “for many db use cases postgresdb is overkill, just use Redis… you get caching too”. I’m not sure exactly what this commentary adds to a real world architecture discussion. The whole thing seems a little sophomoric, tbh.
• staplung 1y ago
  I guess my question is: why bother with a benchmark if the pick is pre-ordained? Is it the case that at some point the results would be so lopsided that you would pick the faster solution? If so, what is that threshold? I.e. when does performance trump system simplicity? To me those are the interesting questions.
  • 000ooo000 1y ago
    >why bother with a benchmark if the pick is pre-ordained Validating assumptions Curiosity/learning Enraging a bunch of HN readers who were apparently born with deep knowledge of PG and Redis tuning
• chiefmix 1y ago
  love that the author finished with: "i do not care. i am not adding another dependency"
• mj2718 1y ago
  My laptop running OOTB Postgres in docker does 100k requests per second with ~5ms latency. How are you getting 20x slower?
  • nasretdinov 1y ago
    That's what I'm struggling with too. Redis can also serve roughly 500k-1m QPS using just ~4-8 cores, so on two cores it should be about 100k-200k at least
    • mj2718 1y ago
      Yep… this is what I expect as a baseline. This is also why I rarely use redis - Postgres at 100k TPS is perfectly fine for all my use cases, including high usage apps.
  • Koffiepoeder 1y ago
    If you look at their lab [0], it seems his NAS is separate from his kubernetes nodes. If he hasn't tuned his networking and NAS to the maximum, network storage may in fact add a LOT of delay on IOPS. Could be the difference between fractions of a millisecond vs actual milliseconds. If your DB load is mostly random reads this can really harm performance. Just hypothesizing here though, since it is not clear whether his DB storage is actually done on the NAS. [0]: https://dizzy.zone/2025/03/10/State-of-my-Homelab-2025/ https://dizzy.zone/2025/03/10/State-of-my-Homelab-2025/
    • mj2718 1y ago
      Sorry but if he’s using a setup that’s 20x worse than a regular laptop then I’m not really interested in his setup. To be fair, I asked the question and you found the answer - lol, my bad. Yes I agree using a nas that adds latency would reduce the TPS and explain his results. “Littles law”
• necovek 1y ago
  I'd be curious to see how Postgres behaves with numeric IDs instead of strings (or another built-in, faster-to-index/hash type). Still leaves you with needing to perfomantly hash your strings into those IDs on top, but mostly as the Postgres plateau of performance compared to purposely built KV DBs.
• Neikius 1y ago
  I skimmed the article, but why is everyone always going for distributed cache? What is wrong with in-memory cache? Lowest latency, fast, easy to implement. Yeah ok, you have 30 million entries? Sure. You need to sync something over multiple nodes? Not sure I would call that a cache.
  • solatic 1y ago
    In the naive/default case, durability is more important than latency. Servers crash, applications are restarted. If it takes a long time to rebuild your cache, or if rebuilding it would be unreliable (e.g. dependency on external APIs) then you court disaster by not using a durable-first cache. If you actually need lower latency then great, design for it. But it should be a conscious decision, not a default one.
  • ahoka 1y ago
    Consistency could be one reason, but I think the best caching strategy is not to need a cache. Adding a (not just) distributed cache early can hide performance issues that can be fixed instead of working around while introducing complexity and maybe even adding data consistency issues and paradoxically performance degradation.
  • lemagedurage 1y ago
    This is modern backend development. The server scales horizontally by default, nodes can be removed and added without disrupting service. With redis as cache, we can do e.g. rate limiting fast without tying a connection to a node, but also scale and deploy without impacting availability.
  • kiney 1y ago
    because PHP scripts started fresh for each request...
  • bearjaws 1y ago
    A lot of people are using NodeJS and storing a massive in-memory object means longer GC time.
  • jerf 1y ago
• gethly 1y ago
  What is all the fuss about? In the ancient times, you put your entry into the database(ANY database), either with TTL or cache tags, and have a cron job that periodically flushes the table. Then in your application you check if you have the entry cached in memory, if not, you check the db entry, if it is not there you build it from scratch and cache it. Why do people complicate things? We've solved caching ages ago.
• nessex 1y ago
  I've got a similar setup with a k3s homelab and a bunch of small projects that need basic data storage and caching. One thing worth considering is that if someone wants to run both redis and postgres, they need to allocate enough memory for both including enough overhead that they don't suddenly OOM. In that sense, seeing if the latency impact of postgres is tolerable is pretty reasonable. You may be able to get away with postgres putting things on disk (yes, redis can too), and only paying the overhead cost of allocating sufficient excess RAM to one pod rather than two. But if making tradeoffs like that, for a low-traffic service in a small homelab, I do wonder if you even need a remote cache. It's always worth considering if you can just have the web server keep it's own cache in-memory or even on-disk. If using go like in the article, you'd likely only need a map and a mutex. That'd be an order of magnitude faster, and be even less to manage... Of course it's not persistent, but then neither was Redis (excl. across web server restarts).
• phendrenad2 1y ago
  I'm glad someone did this analysis. I've also been tempted to remove complexity by removing Redis from my stack. But there's a decent speedup from using Redis, so I'll keep it. (And to the people complaining about this benchmark not being extremely scientifically rigorous: Nobody cares.)
• k9294 1y ago
  > For postgres, the bottleneck was the CPU on the postgres side. It consistently maxed out the 2 cores dedicated to it, while also using ~5000MiB of RAM. Comparing throttled pg vs non-throttled redis is not a benchmark. Of course when pg is throttled you will see bad results and high latencies. A correct performance benchmark would be to give all components unlimited resources and measure performance and how much they use without saturation. In this case, PG might use 3-4 CPUs and 8GB of RAM but have comparable latencies and throughput, which is the main idea behind the notion “pg for everything”. In a real-world situation, when I see a problem with saturated CPU, I add one more CPU. For a service with 10k req/sec, it’s most likely a negligible price.
  • Timshel 1y ago
    Since it's in the context of a homelab you usually don't change your hardware for one application, using the same resources in both test seems logical (could argue that the test should be pg vs redis + pg). And their point is that it's good enough as is.
    • m000 1y ago
      It's a homelab. If it works, it works. And we already knew that it would work without reading TFA. No new insights whatsoever. So what's the point of sharing or discussing?
    • k9294 1y ago
      In a home lab you can go the other way around and compare the number of requests before saturation. e.g. 4k/sec saturates PG CPU to 95%, you get only 20% on redis at this point. Now you can compare latencies and throughput per $. In the article PG latencies are misleading.
• est 1y ago
  reminds me of Handlersocket in MySQL
• truth_seeker 1y ago
  PostgreSQL Tuning further for this use case - Reduce Page Size from 8KB to 4KB, great for write heavy operations and indexed reads. Needs to compile source with those flags, cant configure once installation is done. - Increase Buffer cache - Table partitioning for UNLOGGED Table which the author is using - At connection session level, lower the transaction level from SERIALIZABLE - The new UUID7 in PG 18 as a key might also help as primary indexed KEY type as it also supports range queries on timestamp
• finalhacker 1y ago
  postgres message protocol is much complex than redis. i think it's the bottleneck for such difference.
• smacker 1y ago
  I like using postgres for everything, it lets me simplify infrastructure. But using it as a cache is a bit concerning in terms of reliability, in my opinion. I have witnessed many incidents when DB was considerably degrading. However, thanks to the cache in redis/memcache, a large part of the requests could still be processed with minimal increase in latency. If I were serving cache from the same DB instance, I guess, it would cause cache degradation too when there are any problems with the DB.
  • aiisthefiture 1y ago
    Select by id is fast. If you’re using it as a cache and not doing select by id then it’s not a cache.
    • smacker 1y ago
      absolutely. But when PG is running out of open connections or has already consumed all available CPU even the simplest query will struggle.
      • motorest 1y ago
        > But when PG is running out of open connections or has already consumed all available CPU even the simplest query will struggle. I don't think it is reasonable to assume or even believe that connection exhaustion is an issue specific to Postgres. If you take the time to learn about the topic, you won't need to spend too much time before stumbling upon Redis and connection pool exhaustion issues.
      • IsTom 1y ago
        You can have a separate connection pool for 'cache' requests. You shouldn't have too many PG connections open anyway, on the order of O(num of CPUs).
  • motorest 1y ago
    > But using it as a cache is a bit concerning in terms of reliability, in my opinion. This was the very first time I heard anyone even suggest that storing data in Postgres was a concern in terms of reliability, and I doubt you are the only person in the whole world who has access to critical insight onto the matter. Is it possible that your prior beliefs are unsound and unsubstantiated? > I have witnessed many incidents when DB was considerably degrading. This vague anecdote is meaningless. Do you actually have any concrete scenario in mind? Because anyone can make any system "considerably degrading", even Redis, if they make enough mistakes.
• tzahifadida 1y ago
  I think the moral here is, if you'll ever have less than 1000 active customers per second, don't do micro services, don't use redis, just use a monolith with a simple stack and you'll still be happy, less maintenance, less knowhows, etc... cheaper all around.
• mattacular 1y ago
  For cache, having TTL is invaluable. Having to tune cleanup jobs in Postgres is annoying. Deletes create dead rows (so do updates) so now you have to deal with vacuum as well. The method the author suggested will run into a lot more problems if the service ever needs to scale up beyond what they estimated than a traditional dedicated cache like Redis in front.
• wvh 1y ago
  I've done some benchmarks over the years and 6-7k/s for getting simple data out of a basic Postgres installation seems pretty spot on. The question is when using Postgres as a cache, are you taking away performance for actual, more complex business logic queries. That is going to depend on the level of overlap between endpoints that use caching and those that need more complex queries. What I'd be interested to see is a benchmark that mixes lots of dumb cache queries with typically more complex business logic queries to see how much Postgres performance tanks during highly concurrent load.
• lukaslalinsky 1y ago
  Cache is a very relative term. If I'm caching heavy computation, or perhaps externally acquired resources (e.g web scrapped data), I'd use database as a cache. If I'm caching database results, then I'd obviously use something faster than that.
• h1fra 1y ago
  Having native TTL in PostgreSQL would remove so much unnecessary Redis in the wild.
• jmull 1y ago
  Besides using the word "cache" what does this have to do with caching? It looks like it's just storing the session in postgres/redis. Caching implies there's some slower/laggier/more remote primary storage, for which the cache provides faster/readier access to some data of the primary storage.
• noisy_boy 1y ago
  I have dealt with an abomination of a bespoke setup on Redis that was neither simple key/value nor an RDBMS but a grotesque attempt to simulate tables using key prefix with value being a hash containing "references" to entries in other "tables" (with some "special condition" edge cases thrown in to make it spicy). All with next to no documentation. It took adding many unit tests with generous logging to expose the logic and the underlying structure. That complete madness could have been handled in a bog standard way in PostgreSQL with minimal fuss. All for something that didn't even need to be "real-time". If you see yourself starting with simple key/value setup and then feature requests come in that make you considering having "references" to other keys, it is time to re-consider Redis, not double down on it. Even if you insist on continuing, at the very least, add a service to manage it with some clean abstractions instead of raw-dogging it.
  • fatata123 1y ago
    [dead]
• bhaak 1y ago
  I’m surprised to see this being somewhat controversial. In Rails we just got database backed everything with the option to go to special backends if need be. The only question I have is how do I notice that my current backend doesn’t scale anymore and who or what would tell me to switch.
• enigma101 1y ago
  postgres for everything!
• saberience 1y ago
  Note to anyone reading this blog in the future, this is both very very basic, and also highly misleading. The author makes it seem as though PostGres and Redis are interchangeable and that there's not much difference between them. This is totally misguided and incorrect. Redis can be easily deployed such that any request returns in less than a millisecond, and this is where it's most useful. It's also consistent and stable as hell. There are many use-cases for Redis where Postgres is totally unsuitable and doesn't make sense, and vice versa. Do yourself a favour and ignore this blog (again: inaccurate, poorly benchmarked, misleading) and do your own research and use better sources of information.
• sgarland 1y ago
  Aside from the lack of tuning mentioned, it wasn’t mentioned what variety of UUID was used - I assume v4. If so, the visibility map impacted the performance [0]. [0]: https://www.cybertec-postgresql.com/en/unexpected-downsides-of-uuid-keys-in-postgresql/ https://www.cybertec-postgresql.com/en/unexpected-downsides-...
• paulsutter 1y ago
  Or just use sync.Map, which would be faster and about 10x less work
• Ellipsis753 1y ago
  Great article. Not understanding the hate. I think the jist of it is, you probably have sufficiently low requests/second (<1000) that using postgres as a cache is totally reasonable - which it is. If your hitting your load tests and hardware spend, no need to optimise more.
• BinaryIgor 1y ago
  As expected, Postgres - especially with Unlogged Tables - is fast enough; additionally, having less things to run on your infrastructure and fewer integrations to manage in your app is a hugely underrated benefit. I am just a little bit surprised on the relatively low write performance for both Postgres and Redis here; but as I can see, the tests were run on just 2 CPUs and 8 GB of RAM machine. In my experience, with 8 CPUs, Postgres can easily handle more than 15 000 writes per second using regular tables; I would imagine that it can easily be 20 000+ for the Unlogged variety - who needs more than that to cache?
• sharadov 1y ago
  Postgres needs to be tuned for the workflow and the hardware. It's a travesty to run it on default settings. All it takes is 5 mins to do it. Use pgtune - https://pgtune.leopard.in.ua/ https://pgtune.leopard.in.ua/ I know the author concludes that he would still use Postgres for his projects. But, he would get much better benchmark numbers if it was tuned.
• dvcoolarun 1y ago
  I get the argument for using Postgres, but it's mostly about the convenience of the tool, specific constraints, and the bottlenecks it solves, especially with TTL and a cache interface already implemented. And dealing with unlogged table contents are not crash-safe. I believe Redis would have performed better with more allocated CPU.
• tarasyarema 1y ago
  I completely agree with your view! I use postgres for all, as the cost of switching to the (scalable) solution for this kind of problems is low, and in the ens let’s be realistic about how “viral” your app can get… When I worked in a bigger company in the past we used postgres to store raw blobs for data transformation pipelines (+1T table), and queries to it were instant due to good index usage. Others might have gone to BigQuery or something else making more complex and def more expensive. PS: I love tools like Temporal, Hatchet or Oban that rely on Postgres and can scale a ton too.
• ricardobeat 1y ago
  At this small scale, if all you need is a k/v cache, and not any of the Redis data structures, just do it in-memory at application level.
• jdc0589 1y ago
  the redis average latencies are pretty surprisingly high to me, but can probably be explained by your lab setup/hardware. 1. im surprised the latencies for redis are as high as they are. single key lookup operator is very commonly <= 2ms in my experience. 2. your throughput looks pretty solid, which makes it even weirder that latencies are relatively high. Like I said its probably just hardware though. Ive written a handful of redis backed services where the read APIs have a p99 10ms. In those instances the api infra wasn't anything too special, but it was a decent redis setup (elasticache of some middling tier).