31–40 of 82 posts
If it's to serve as a cache on an application level, memcache seems like it would be simpler and faster. While I do like Redis, I can see why you'd be careful introducing it. Redis can blur the boundaries between caching and data storage a bit, but it's just so handy.
It gives me anxiety how much truly awful advice is upvoted here. It feels like children playing in a sand pit, and then one of the children dumps a box of rat poison on the ground, and some kid says how rat poison is actually good for you because it contains minerals or something. So they all start quickly scarfing it down. You try to tell them rat poison is bad for them, and then several of the kids start defending rat poison, with one lecturing you for being so negative about rat poison. I guess I should just let the kids poison themselves, but it's a terrible thing to watch.
Calling Postgres experts: Why, exactly, do we need to put a memory cache such as Redis in front of Postgres? Postgres has its own in-memory cache that it updates on reads and writes, right? What makes Postgres' cache so much worse than a dedicated Redis?
Why wouldn't you simply use SQLite (or some other in-memory flavor of SQL) instead of hacking the main Postgres db and adding load to the primary instance? The author makes a valid point that there's something nice about using familiar tooling (including the SQL interface) for a cache, but it feels like there are better solutions.
> hacking the main Postgres db and adding load to the primary instance nobody said this had to be on the primary database server, and how is this hacking? Is every app server going to have its own local "sqlite cache"? Or is it going to use one of the sqlite server/replication things? So why not just use PG?
I'm sure there are many cases when that makes sense, but there are many cases when that's also overkill. An in-memory cache inside your server will give you better performance, and a lot of less infrastructure maintenance complexity.
For projects where I know the team will remain small (less than let's say 15 developers), I usually push to keep the architecture as simple as possible. I've used something similar in the past, but kept the expiration code in the app code (Python) instead of using "fancy" Postgres features, like stored procedures. It's much easier to maintain since most developers will know how to read and maintain the Python code, t…
> Let's say you compute a value inside a transaction, cache it in Redis, and then the transaction fails. That just sounds like an application bug. Nothing should be done with the query result anyway until the transaction either completes our rolls back.
Earlier quoted context omitted.
> Let's say you compute a value inside a transaction, cache it in Redis, and then the transaction fails. That just sounds like an application bug. Nothing should be done with the query result anyway until the transaction either completes our rolls back.
Transactions can fail because they conflict with other transactions happening at the same time. It's not an application bug. It's real life transactions happening on a production system. It's normal for that to happen all the time. The app can retry, etc., but it should be expected to happen. Having to deal with distributed transactions is not something easy. Especially when they're part of many different systems. Fo…
Calling Postgres experts: Why, exactly, do we need to put a memory cache such as Redis in front of Postgres? Postgres has its own in-memory cache that it updates on reads and writes, right? What makes Postgres' cache so much worse than a dedicated Redis?
Because you can’t scale out just the cache part of Postgres, one machine can only have so much memory
Sometimes I feel like the articles posted here are elaborate trolls. Like they wanted to know what the purpose of a cache is and how/when to implement one, but they didn't want to do research, so they came up with the worst idea they could imagine and blogged about it, hoping someone on HN would tell them the right way (or just laughing at people trying to correct them). It gives me anxiety how much truly awful advic…
At least a couple of counterpoints on why this would be a bad idea and offer a better approach.
Calling Postgres experts: Why, exactly, do we need to put a memory cache such as Redis in front of Postgres? Postgres has its own in-memory cache that it updates on reads and writes, right? What makes Postgres' cache so much worse than a dedicated Redis?
All of these questions go away or are greatly simplified with redis.