If you already have Postgres in your project and now you get the requirement for an additional cache store, I think it will be less complicated to reuse what you already have instead of adding another DB to your stack.
Of course, at some point of scaling needs a dedicated cache store will make sense anyway.
(Just some justifications from a german engineer :) )
True. However, since cache is usually transient, adding this key-value store/cache is as easy as "docker run redis". No need to provision block storage, and it's really lightweight in comparison.
(that being said, I try really hard not to judge; after all, i'm not without fault: it's 2021 and i'm using bash over cgi-bin to serve web pages for my own hobby projects :))) )
> True. However, since cache is usually transient, adding this key-value store/cache is as easy as "docker run redis". No need to provision block storage, and it's really lightweight in comparison.
If you're using postgres for caching only, as you do Redis, then you also do not need to provision block storage.
If you happen to already have Postgres running for other uses, you also do not need to provision block storage.
Finally, I would add that Redis clients such as Redisson are resource hogs that cause performance problems on apps, while pg clients are barely noticeable.
> I'd be interested on why exactly you think that Redis shouldn't be called a DB?
Normally I think when people say "Redis isn't a DB", they mean "an update will always return successfully before the data has been committed to storage".
If your user makes a change, you record that in a Postgres database, you've informed the user of your success, and the power goes out on the Postgres database, then the user will not have been misled; the data is in the database. If you did it with a persistent Redis system, there is some reasonable probability that the user has been misled and their data is no longer available.
I don't think this is a good definition of a database. In reality, we take various decisions, some of which increase the likelihood data will be preserved across some kinds of failures, some of which decrease the likelihood. No one would say "you don't have a database because you take daily backups from a single, unreplicated Postgres instance". They say "you have made decisions which increase the possibility of dataloss under certain circumstances" (well, they say things I translate that way).
And there I'm unsure what we consider essential characteristics of a database.
This characteristic you're mentioning is essential for your persistence database, but maybe not so much for a derived read-only databases (e.g. when using the CQRS pattern). Those guarantees and characteristics are often a trade off anyway.
I certainly agree with you. As engineers, we should be comfortable with properties and requirements, and selecting the combinations of tools and self-written code which match them most maintainably.
Unfortunately, it's easier to think in terms of tools and substitutes. For instance, it's difficult for us to say "I used a combination of handwritten code and redis to provide some of the guarantees that I would've got for less handwritten code and Postgres". However, this is exactly that sort of article: it argues that sometimes, it is better to use Postgres even if the features you want a more naturally provided by Redis.
> And there I'm unsure what we consider essential characteristics of a database.
I doubt there really is anything. I don't think it's possible to actually narrow down "database" to some precise definition, so I think for instance the person who said "only an idiot thinks Redis is a database" needs to explain what they mean by "a database" before we can discuss the merits of their position.
> And there I'm unsure what we consider essential characteristics of a database.
Simple, people know other databases (Postgres, MySQL, SQLite, SQL Server, Berkeley DB, CouchDB, ....), those have many things in common, so when they hear "Redis is a database" they unconsciously assume Redis has properties those other products have. And it has few all those products have.
Just fyi: If you're deep in a thread and the Reply button doesn't show on the comment you want to reply to, you can click on the time. The reply button will be available there. Basically, permitted thread depth is relative to the view, not absolute to the root.
Most products labelled as "database" afford most if not all of the ACID guarantees. Redis offers none by default. It's a database in the loosest sense of the word, so it's a database alright, but then so is a text file.
The problem is that in practice, some people will assume that it, being a "database", has similar properties to the other databases they know when it doesn't. I've had heated debates in meetings, and I wasn't just spewing an opinion but pointing at the documentation. In the latest case, that involved replication in a cluster, there is absolutely no guarantee (or there wasn't at the time that happened) of consistency between members. The developers had assumed there was. It's the kind of assumption that works just fine and dandy in a staging environment, but breaks subtly and painfully in production, eventually.
It offers no guarantees commonly afforded by databases. I have seen several instances, real life instances of people incorrectly assuming those guarantees when using Redis. So sure, if you know exactly what you're doing, you can use Redis as a database, but the reality is that it's much safer to assume you can't as a first approximation.
Calling people "idiots" here is a public service. I'm sure there are non idiots who can prove me wrong, but they're the minority among production users of Redis that rely on it for non perishable data.
> Only idiots think [x]... I'm not calling people names to be mean here; I'm trying to save your lives.
If you don't mean to call people names, my advice is to not call them names.
For instance, in this particular case, a perfectly intelligent person whose expertise is in another area of software development might have been misinformed. In this case, you're going to achieve your goal (saving "lives") for more effectively if you state (a) what you mean by "a DB" and (b) why it is always a worse decision to use Redis as a DB than to use some other tool for that end.
I mean it in the same way you'd put a "not to be operated by morons" sticker on dangerous industrial equipment. Redis offers little to no guarantees, particularly in a cluster, and unless your data is perishable (session state, cache ...) and you now exactly what you're doing, that's less than what most users expect. I've seen it happen several times already.
> I mean it in the same way you'd put a "not to be operated by morons" sticker on dangerous industrial equipment.
I've never seen a sticker like that on dangerous industrial equipment. I'm pretty sure if you tried to put a sticker like that on dangerous industrial equipment, you would not limit your liability one iota. You would certainly receive at least this much pushback, and probably more. Normally, for a warning to be effective, it needs to say what it is warning about.
>Redis offers little to no guarantees, particularly in a cluster, and unless your data is perishable (session state, cache ...) and you now exactly what you're doing, that's less than what most users expect. I've seen it happen several times already.
It reads like you're making a different claim now than you did before. Before, you said something like "you're an idiot if you use Redis as a database", and we were concerned by what you mean by "a database" and how useless it is to just call someone an idiot. Now it seems like you mean "you'd have to be an expert or an idiot if you decide to use Redis at all for any purpose".
Now, I think it's still useless to call someone an idiot - it would be more productive to play with a cat than call someone an idiot for using a widely regarded tool.
In this form we don't need to worry about what you mean by a database - it's the tool that is the signal, and you need to take into consideration its properties before you decide to use it, rather than reading marketing copy or looking for a point on your resume.
And I think trustworthy, expert, well-trained people can make judgements that turn out to be wrong. A person can make a very good case to use Redis which turns into a nightmare by future requirements changes or by an incorrect weighting of the pros and cons.
I think you're just trying to say something which I would express as "The burden of proof lies on the person who wants to add Redis to a system, and on any additional use of Redis in a system which already has it. If you're considering simplifying a system which uses Redis and something else so that it uses only one of them, you almost certainly want to remove Redis rather than the other tool." If so, I think that's fair (even though the word "idiot" will make it harder to get your message across, and the mention of "as a database" is a distraction - you can only use Redis as a database and the question is how much persistence do you need and how much do you get), but I think you should have added the why to the original message: "Redis offers little to no guarantees, particularly in a cluster, and unless your data is perishable (session state, cache ...) and you now exactly what you're doing, that's less than what most users expect." Like this, it emphasises the risk of "accidental creep" as well as the persistence limitations you're worried about.
After all, any idiot who reads your original text is going to ignore it. If they're willing to decide based on reputation, Redis is a well known tool used by many businesses and you're a pseudonymous commenter on social media. If they're willing to decide based on facts, you didn't give them any. And if they're willing to decide based whether or not they assess themselves as an idiot, they aren't going to assess themselves as an idiot.
Of course, at some point of scaling needs a dedicated cache store will make sense anyway.
(Just some justifications from a german engineer :) )