Redis vs Postgres

Your app needs to remember things. That sounds like one job. It’s two, and picking the wrong tool for either is how you end up with a fast app that quietly loses orders.

The difference in one line

Postgres remembers on disk. Redis remembers in memory.

Everything else — the speed, the durability, the data types, the price — follows from that single fact. Memory is roughly a hundred thousand times faster to reach than a spinning disk, and rather faster than an SSD too. Memory also forgets the instant the power goes.

What that actually means

Pull the plug on a Postgres box mid-transaction and, when it comes back, your committed data is still there. That’s not luck. Postgres writes changes to a write-ahead log before it acknowledges them, so there’s always a record on disk it can replay.

Pull the plug on Redis and, by default, you lose whatever was in memory since the last snapshot. Redis can persist — AOF and RDB both exist — but you are trading away the speed you chose it for, and you still don’t get transactional durability guarantees on the level Postgres gives you.

So the question is never “which is better”. It’s what happens if this particular piece of data disappears?

The test that decides it

Ask one question about the data in front of you:

If this vanished right now, would anyone be harmed, out of pocket, or lied to?

• Yes — an order, a payment, a user account, an audit record. That’s Postgres.
• No — a session token, a rate-limit counter, a cached API response, a leaderboard. Redis.

That’s it. That’s the whole decision, and it survives contact with almost every real system.

Where people get burned

The classic mistake is putting the shopping cart in Redis because carts feel ephemeral. Then Redis restarts during a deploy, a few hundred carts empty themselves, and support spends the afternoon apologising. The cart felt temporary; the revenue attached to it wasn’t.

The mirror-image mistake is running session lookups through Postgres on every single request. Now every page load costs a disk read and a connection from a pool that has maybe a hundred slots. The app works fine in staging with three users and falls over on launch day.

Using both, properly

Most real systems run both, and the pattern is boring on purpose:

• Postgres is the source of truth. It owns the data.
• Redis is a derived copy you can afford to throw away — a cache in front of expensive reads, a session store, a queue, a counter.

The rule that keeps this honest: you must be able to delete your entire Redis instance and have the app still be correct, just slower. If wiping Redis loses information that exists nowhere else, you haven’t built a cache. You’ve built a database with no durability, and you’ll find out on the worst possible day.

The rule

If losing it would cost you money or trust, it goes in Postgres. If losing it just costs you a millisecond, Redis is fine.