I think the best choice depends on your idea of data architecture. Think SQL as a table where all the rows have the same definition of columns and NoSQL as a "folder" where all the records are files with a more flexible content inside. In my case, I would implement MySQL to the more "rigid" or static parts of the web app and Mongo to the more "free form" part. for instance if every user will have publications and each publication starts with a standarized set of attributes (think, created at, user_id, title, etc.) that should go in MySQL. But when the same content can have multiple fields that aren't necessarily mandatory to all of them (think like in a store where computers can have certain charasteristics, while refrigerators have another set of attributes) this can be achieved with a MongoDB document. Also the NoSQL serves as a more flexible medium so yo could add new attributes later to the new publications. In the long run: if you see that there is some sort of "standarization" in your data, that should be handled with MySQL, if not, it should be Mongo, since the alternative is some sort of EAV implementation which most of the time fall under a "bad practice, or bad design pattern in SQL"