I think you're talking about a few different points here that aren't necessarily related. Persistence (which is available in MongoDB) has nothing to do with te

I think you're talking about a few different points here that aren't necessarily related. Persistence (which is available in MongoDB) has nothing to do with testing of a model (a single document inside a collection). Some actually see that as an advantage of using a schemaloose (yes I just made that up) storage like MongoDb. I don't need to have a whole document defined in order to test the functionality of an embeded object in that document. Yes, you're relying on the application alone to enforce the model, but that's a trade off made up front regardless. As for modeling and the cost of refactoring, I think it depends on more than just the storage facility you're using. The code that handles your modeling in MongoDB is only as brittle or robust as you choose, same as a SQL solution. Yes, it helps if you think more up front about how you are going to query the data that you store using MongoDB as this will help to minimizing refactoring later on. However, I think the pain associated with moving part of a table to another / new table in SQL is no less painful than moving an embedded object or other data structure around in MongoDB. In both cases you're moving data and affecting changes in your application.