I'm not in love with relational databases or ORM by any means, but your post sounds like document database marketing. Document databases are usually not a perf

I'm not in love with relational databases or ORM by any means, but your post sounds like document database marketing. Document databases are usually not a perfect fit either in my experience (I have worked on a few MongoDB projects). The fact remains that you are responsible for storing the state and retrieving that state in an optimal way (this is where you usually end up writing some custom document db queries, or creating large multi-indexed collections specifically for reports). What would be ideal is if state was managed transparently for you using a lot of shared / clustered memory and a transaction log. I.e. something like Terracotta in the JVM (No I don't work for them, and have never even used it. I just love the theory behind it). You'd still want to archive data somewhere (Relational or Document), so you would still have that complexity for large datasets. Forget NoSQL, how about NoFetch? (oversimplified perhaps).