i love redis so fucking much

Should I use it for async queue's? Is it faster than storing queue's in the database?
By queue's I mean laravel jobs

@NarkoCat its probably gonna be faster than your db, yeah

Remember it's all in RAM. Random access memory and volatile. So you can't rely on it

@Mba3gar it dumps itself on the storage regularly

@NarkoCat Laravel Horizon does it all for you, if you're looking into Laravel queued jobs on Redis.

@Mba3gar RDB makes it less volatile, AOF makes it as trustworthy as any other database.

@yellow-dog @bittersweet well it might be but not very safe you know right ?

@Mba3gar With Redis AOF "everysec" you can indeed lose up to a second of data persistence. Usually, that's not a huge problem.

If it is, you can also set AOF to persist always, sacrificing a bit of write performance for absolute data safety.

Redis is amazing. Don’t store data in redis you can’t get elsewhere. Redis is fast and wonderful. But also don’t ever scan the entire key space either.

I do feel like almost all people underestimate Redis.

It's not just a key-value store. Sure, if you store all your data as key-value using SET/GET, it's a key-value store.

But you can store Geo info. You can add secondary indexes, even r-tree/kd-tree indexes. zsets are amazing for indexing, to create complex aggregates. You can use it perfectly fine as a graph database. You can use it for pub/sub or to process streams with kafka-style consumer groups.

People have implemented ML tensor datatypes for Redis, and re-built a faster SQLite clone with complete feature-parity on top of Redis.

So whenever someone says: "You shouldn't use Redis for x, because it's only a key-value store" I always feel like saying "Yeah and Java is only used for Minecraft addons".

Of course, it's not always the perfect solution; but for many problems it CAN be used pretty effectively.