> He even admits Postgres maxxed out its 2 cores, but Redis was bottlenecked by the HTTP server.

What exactly is your point? That you can further optimize either option? Well yes, that comes at no suprise. I mean, the latencies alone are in the range of some transcontinental requests. Were you surprised that Redis outperformed Postgres? I hardly think so.

So what's the problem?

The main point that's proven is that there is indeed diminishing returns in terms of performance. For applications where you can afford an extra 20ms when hitting a cache, caching using a persistent database is an option. For some people, it seems this fact was very surprising. That's food for thought, isn't it?

▲

hvb2 10 hours ago | parent [-]

I've done this many times in AWS leveraging dynamodb.

Comes with ttl support (which isn't precise so you still need to check expiration on read), and can support long TTLs as there's essentially no limit to the storage.

All of this at a fraction of the cost of HA redis Only if you need that last millisecond of performance and have done all other optimizations should one consider redis imho

▲

motorest 9 hours ago | parent | next [-]

> I've done this many times in AWS leveraging dynamodb.

Exactly. I think nosql offerings from any cloud provider already supports both TTL and conditional requests out-of-the-box, and the performance of basic key-value CRUD operations is often <10ms.

I've seem some benchmarks advertise memory cache services as having latencies around 1ms. Yeah, this would mean the latency of a database is 10 times higher. But relative numbers matter nothing. What matters is absolute numbers, as they are the ones that drive tradeoff analysis. Does a feature afford an extra 10ms in latency, and is that performance improvement worth paying a premium?

▲

re-thc 9 hours ago | parent | prev [-]

> All of this at a fraction of the cost of HA redis

This depends on your scale. Dynamodb is pay per request and the scaling isn’t as smooth. At certain scales Redis is cheaper.

Then if you don’t have high demand maybe it’s ok without HA for Redis and it can still be cheaper.

▲

hvb2 8 hours ago | parent | next [-]

You would need to get to insane read counts pretty much 24/7 for this to work out.

For HA redis you need at least 6 instances, 2 regions * 3 AZs. And you're paying for all of that 24/7.

And if you truly have 24/7 use then just 2 regions won't make sense as the latency to get to those regions from the other side of the globe easily removes any caching benefit.

▲

odie5533 6 hours ago | parent | next [-]

It's $9/mo for 100 MB of ElastiCache Serverless which is HA.

It's $15/mo for 2x cache.t4g.micro nodes for ElastiCache Valkey with multi-az HA and a 1-year commitment. This gives you about 400 MB.

It very much depends on your use case though if you need multiple regions then I think DynamoDB might be better.

I prefer Redis over DynamoDB usually because it's a widely supported standard.

	▲	motorest 4 hours ago \| parent [-]
		> It's $9/mo for 100 MB of ElastiCache Serverless which is HA. You need to be more specific with your scenario. Having to cache 100MB of anything is hardly a scenario that involves introducing a memory cache service such as Redis. This is well within the territory of just storing data in a dictionary. Whatever is driving the requirement for Redis in your scenario, performance and memory clearly isn't it.

▲

ahoka 7 hours ago | parent | prev [-]

A 6 node cache and caching in DynamoDB, what the hell happened to the industry? Or people just call every kind of non business-object persistence cache now?

	▲	hvb2 5 hours ago \| parent [-]
		I don't understand your comment. If you're given the requirement of highly available, how do you not end up with at least 3 nodes? I wouldn't consider a single region to be HA but I could see that argument as being paranoid. A cache is just a store for things that expire after a while that take load of your persistent store. It's inherently eventually consistent and supposed to help you scale reads. Whatever you use for storage is irrelevant to the concept of offloading reads

▲

motorest 9 hours ago | parent | prev [-]

> At certain scales Redis is cheaper.

Can you specify in which scenario you think Redis is cheaper than caching things in, say, dynamodb.

▲

odie5533 6 hours ago | parent [-]

High read/write and low-ish size. Also it's faster.

▲

motorest 6 hours ago | parent [-]

> High read/write and low-ish size. Also it's faster

You posted a vague and meaningless assertion. If you do not have latency numbers and cost differences, you have absolutely nothing to show for, and you failed to provide any rationale that justified even whether any cache is required at all.

▲

odie5533 5 hours ago | parent [-]

At 10k RPS you'll see a significant cost savings with Redis over DynamoDB.

ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response)

DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests)

	▲	hvb2 an hour ago \| parent \| next [-]
		> At 10k RPS You would've used local memory first. At which point I cannot see getting to those request levels anymore > ElastiCache Serverless (Redis/Memcached): Typical latency is 300–500 microseconds (sub-millisecond response) Sure > DynamoDB On-Demand: Typical latency is single-digit milliseconds (usually between 1–10 milliseconds for standard requests) I know very little use cases where that difference is meaningful. Unless you have to do this many times sequentially in which case optimizing that would be much more interesting than a single read being .5 ms versus the typical 3 to 4 for dynamo (that last number is based on experience)
	▲	motorest 4 hours ago \| parent \| prev [-]
		> At 10k RPS you'll see a significant cost savings with Redis over DynamoDB. You need to be more specific than that. Depending on your read/write patterns and how much memory you need to allocate to Redis, back of the napkin calculations still point to the fact that Redis can still cost >$1k/month more than DynamoDB. Did you actually do the math on what it costs to run Redis?