Traditional SQL databases provide some baked in guarantees regarding relationships between data and data structure. You design a schema and the server ensures t

Traditional SQL databases provide some baked in guarantees regarding relationships between data and data structure. You design a schema and the server ensures that required columns exist, relationships between keys are enforced, and that all data is of the appropriate type. You're also given guarantees that certain things are done atomically. This means that a series of actions are performed with the promise that nothing will interfere between step one and step N. This promise is fulfilled through the use of transactions which incur a performance hit. NoSQL has become an increasingly broad term used to indicate some other storage strategy than traditional SQL databases provide. NoSQL databases tend to operate on a more basic level and omit things like transactions in favor of performance. Schemas are also disregarded to allow arbitrary storage requirements to be addressed with ease; although, you lose the traditional guarantees that a schema can provide. This is just my opinion, but I think it's a lot easier to setup a clusterfuck storage nightmare using a NoSQL database. If you're unfamiliar with SQL and NoSQL, you're most likely going to end up in a safer and more recoverable situation going with something tried and true like PostgreSQL. If you're not sure whether you need a NoSQL system, then you don't need one. They serve a use case and performance requirement that very few websites demand. That being said, when the need does arise, they can be an indispensable for scaling out a large website. Like anything else, they're not a magic bullet that you just drop into your storage strategy and go on your merry way. Rolling them out requires lots of planning just like any other large scale deployment does.