"I wouldn't pick an ORM even for caching, ORMs are typically a multi-layered blackbox magic based God class, thus very hard to debug when things hit the fan." -- THATS THE TRUTH! Im still scarred from various production issues over the years where the cache keeps filling up all the memory and crashing for no discernable good reason. Yeah - theres a stack trace - it says that 3rd party rats nest library code I have no control over failed... Great, Thanks! ( Hey boss! I fixed that cache bug - I changed the 3rd party code in our dependency - now we're upgrade locked forever!!! Great right!! )

I do things like your example here when I know at what interval the underlying data is capable of changing. Batch process runs every night at midnight, no big deal, kill and rebuild the cache when it finishes. If you know when the data can change you can rebuild the cache on demand or let it gradually repopulate on its own nicely.

The nasty part of caching is knowing when something changed in the underlying database such that the now invalidated cache entries can be evicted. Seems to me that when it absolutely needs to be up to the second kind of correct, we're best off skipping the "efficiency gain" a cache MAY offer in favor of direct SQL to an actual database connection.

You can spend money on a BIG HOG of a database one time and know precisely how much you will spend to get the speed and reliability your use case demands. If you start trying to solve this with the caching/ORM route you're expense is NOT fixed. Dev Hours vs. Hardware Cost - Im buying hardware almost every time!