I'm still a newbie so I have a hard time articulating this, just a couple years into my career. The "rule of thumb" that I've worked up so far is that document

I'm still a newbie so I have a hard time articulating this, just a couple years into my career. The "rule of thumb" that I've worked up so far is that document stores are great for records that are useful in isolation but are possibly heterogeneous in nature. (of course there's nothing stopping you from storing foreign keys and doing "joins", or just storing data with a strict schema). Logs and configuration are both simple use cases. One example from my work is ingesting usage information from a variety of products, like a system that takes in information about all your utilities - power, water, gas, and so on. Each product will have its own attributes that's important to describing it. In a relational world, you might: add columns to your table as new attributes need to be described; come up with some kind of composite attribute system where you try to encode multiple pieces of information in one field; go for a star schema so every product gets its own table; or pivot so that each "record" is represented by multiple rows and the attribute's identifier is a field. Each of those approaches has their ups and downs but they're all present due to hard schemas. In a NoSQL world, a single table can have wildly varying records, each of which is useful on its own without needing to spread metadata into other tables.