I love Postgres, and I agree with the general sentiment. But I read the (growing) genre of "use Postgres for everything" articles and they imply a difficulty in running other software that I just don't see.

I'm thinking of Redis in particular. If you're using it as incredibly fast but not critical storage, it's trivial to set up and it ~never crashes or requires maintenance. It creates no headaches, and in exchange gives me a k/v store that I can thrash without worrying about performance (I know it's fast), downstream impact (am I slowing down critical-path SQL queries), etc. Especially in the age of LLMs, which I've found to be great at devops-type tasks, I feel slightly less compelled to simplify my stack.

▲

gentlewater 33 minutes ago | parent | next [-]

Only problem for me vs using your primary DB is that Redis has no redundancy unless you run it in cluster mode. For us that means when the kubernetes node restarts, availability degrades. Could of course enable clustering, but at that point it isn’t dead simple anymore. And using the DB is.

	▲	preisschild 12 minutes ago \| parent [-]
		If you run kubernetes, it might be worth looking at valkey/valkey-operator that manages a valkey cluster for you.

▲

alex_smart 34 minutes ago | parent | prev | next [-]

The problem only arises when you have to worry about persistent state. As soon as you have to worry about that, you have to think about backups, replicas, disaster recovery drills and so on. It is much easier to solve for that can of worms for one system than three.

▲

dinkleberg 2 hours ago | parent | prev | next [-]

Yeah I've found this quite odd. Even the LLMs want to pressure you to not use Redis and go all in on Postgres. Postgres is great, and I usually use it. But Redis is so trivial to add to your stack and it does what it does really well. Why not use the right tool for the job?

▲

c0_0p_ 25 minutes ago | parent | next [-]

Presumably this is because LLMs just echo all the pro-Postgres Medium articles they've been trained on. They don't have any actual experience.

▲

happyPersonR an hour ago | parent | prev | next [-]

LLMs from hyperscalers allow for paid advertising

▲

Faaak an hour ago | parent | prev [-]

because if you already have postgres, and dont need thousands of k/v per second, then postgres can do the same ?

	▲	stickfigure an hour ago \| parent [-]
		If you're stressing your database, offloading some work to Redis can buy you a lot of Postgres headroom. But sure, start with YAGNI.

▲

Xeoncross 2 hours ago | parent | prev | next [-]

Redis really is a great piece of software. Low memory, high-performance, feature-rich, and stable. Really hard to beat it for places where you want a durable cache even if technically you can use something else.

▲

deepsun an hour ago | parent | prev | next [-]

And Redis has auto-delete rows (aka TTL). In Postgres you need a cron job to clear stale rows.

	▲	pooloo an hour ago \| parent [-]
		This is one way to handle the problem, but not the only...

▲

stavros 2 hours ago | parent | prev [-]

Oh no, redis is super simple to set up and use. It's just that setting it up is not as simple as not setting it up.

▲

tracker1 2 hours ago | parent | next [-]

For smaller projects and locally, I'm running background services via a compose file... it's a few lines of configuration, and just works. Redis is crazy low hanging fruit.. even job queues that run over Redis make a bit more sense than with Postgres more often than not.

I'm far more hesitant to throw a more formal MQ in the mix though... mostly from experience in that a lot of mid level ("senior") developers don't really understand queues very well at all. Even if conceptually, using tables for queues is more complex.

That said, I will use PG for workflows similar to K/V, Document (JSONB) and other structures over reaching for say MongoDB, etc.

▲

willsmith72 33 minutes ago | parent [-]

Of course spinning up a hello world of anything is easy. Now introduce monitoring, change controls, version upgrades, multiple environments and regions

It's not that it's necessarily complex. But if you don't need it, don't use it. The business could use your time elsewhere

	▲	tracker1 26 minutes ago \| parent [-]
		For a redis cache? I think you're way over-valuing the effort it takes to keep a redis instance running. For a persistent store.. sure... but that's true for PostgreSQL as well, which has some pretty painful major version migrations by comparison to other options.

▲

wuliwong 2 hours ago | parent | prev [-]

OK, but it is relatively easy to setup. Obviously, nobody thinks it is _literally_ effortless.

▲

munk-a 2 hours ago | parent [-]

Every extra straw you put on the back of your ops team, especially when you're a young company, adds weight. It's good to be choosey about which technologies actually justify that expenditure.

	▲	wuliwong an hour ago \| parent [-]
		Your response is a Strawman argument. I was simply saying that nobody thinks that Redis is literally effortless. I was pointing out that the person's comment was not helpful as they were pointing out that Redis installation does actually require effort. A better response to my comment could have been "just let it go" or something. ₍₍(˶>ᗜ<˶)⁾⁾