> 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.