What you're describing sounds a lot of why NoSQL databases came into being. A cache is usually very fast at a very narrow data problem. Caches are almost always

What you're describing sounds a lot of why NoSQL databases came into being. A cache is usually very fast at a very narrow data problem. Caches are almost always flat bits of data with no structure. They're also eventually consistent. They are purpose built data structures for a very small piece of the problem done over and over. An RDMS is a centralized, consistent source of truth, with more normalized data, that can answer most questions with reasonable performance. When you remove the RDMS, what happens? - You lose the ability to answer ad-hoc relational questions (what stuff does the user own? And in those things, which of them is located in Chicago?). This means building a new feature means building a new "cache" aka a brand new data structure _just for this one use case_ that might be a one-off - You lose a centralized PoV on your data consistency. One view of the cache says the user's item is in Chicago. Another says its en route to LA from Chicago. How do you resolve these conflicts? Are you going to build your own consistency systems? Based on what exactly? Now you've essentially built a new kind of distributed database. - Much of the time we don't need caches. If you always have to bust your cache, the cost of constantly rebuilding a cache, just to throw it away, can greatly exceed any value from that cache. Most people can just read from the RDMS and get what they need for 90% of the use cases in most apps. BTW I used Redis as a primary DB for a few years for Quepid. You can read the full story here https://www.slideshare.net/AllThingsOpen/stop-worrying-love-the-sql-a-case-study https://www.slideshare.net/AllThingsOpen/stop-worrying-love-... Long story short, it was fine, but Redis didn't allow for much structure. There was a lot of "logical" relational data modeled very awkwardly. It made it hard to extend beyond the original data model.