And they too can slow things down. Like all caches can. Like Redis can. Cache is a leaky abstraction.

(Although a materialised view is more like an index than a cache. The view won't expire requiring you to rebuild.)

I believe this same language use is what makes this article confusing: Redis is not a cache, it is a key value store. Caching is usually implemented using key value stores, but it is not an abstraction (leaky or not).

In RDBMS contexts, index really is a caching mechanism (a cache) managed by the database system (query planner needs to decide when it's best to use one index or another).

But as you note yourself even in these cases where you've got cache management bundled with the database, having too many can slow down (even deadlock) writes so much as the database tries to ensure consistency between these redundant data storage elements.

I thought Redis grew up as a KV cache and persistent storage came later.

In some sense though. If it ain't L1 it's storage :)

Maybe Redis started up as an in-memory KV store focused on caching use cases, but it was still a KV store that could be used for caching, or not.

Even if you use "cache" in the name (eg. memcached), that's still not a cache, even if it's a KV store designed for caching.