Hacker News new | ask | show | jobs
by techscruggs 827 days ago
This appears to be riding the [Solid Cache](https://dev.37signals.com/solid-cache/) idea that DHH has started espousing. At the core of this idea is that SSD's are sufficiently fast for caching. Sure, this may work for 37signals, but that is because they manage their own hardware. That is the exception and not the rule. And, per [this discussion two weeks ago](https://news.ycombinator.com/item?id=39443679). SSD's aren't as fast for most of us that leverage "the cloud".

Sure, you can do it, but why? I am all for removing complexities in my infrastructure. That said, Memcached and/or Redis are both rock solid and dead simple.

This just seems to be a waist of time 99.999% of use cases.
2 comments
wlll 827 days ago
> Sure, you can do it, but why?

Re. Solid cache they effectively answered this in the post. The cost is less meaning they can cache more so p95 response time goes down. If you're not constrained my money you can just buy a bigger memcached or Redis of course.

If you're talking about moving things to Postgres /in general/, then cost and/or complexity are compelling reasons to do so. Small engineering teams, small budgets, simplifying and reducing cost can really help. Obviously it's not suitable for everyone but it's nice to have the option.

link
koliber 827 days ago
In general, caches need to be fast. However, the Solid Cache article you linked says:

> On Basecamp, compared to our old Redis cache, reads are now about 40% slower. But the cache is 6 times larger, and running on storage that’s 80% cheaper.

It seems that their caching needs don't require the speed that Redis provides. Instead, they can get an overall performance improvement in their application if they cache more things -- that's why they want a bigger cache.

Based on this, it seems that Redis was too fast and too expensive. Being self-aware of your needs is key. This way, BaseCamp could tailor a solution that suits their needs.

You don't always need the fastest, the biggest, the most scalable, or the cheapest. If you know the thresholds, you can come up with a better tradeoff.

link