The debate over SQL and NoSQL has been raging for a long time, but has been amplified with the emergence of big data and its importance in the modern enterprise. And while there are proponents on the extremes of both, most developers and database administrators are using both.
SQL
SQL (Structured Query Language) has been around since the 1970's and, until recently, was the predominant database architecture of most applications. SQL is a Relational Database Management Systems (RDBMS), meaning that data is organized into rigid, pre-defined tables, each containing columns and rows.
The advantages of SQL are numerous: it is widely supported by the largest enterprise vendors, specifically Oracle and Microsoft. Learning the SQL language is also relatively wasy and has a very low learning curve. Relational databases like SQL are great for data models that are unlikely to change and have a very clear structure.
NoSQL
NoSQL has emerged in recent years as a powerful alternative to SQL. As its name suggests, NoSQL is a non-relational database management system and allows for much greater flexibility in the design of a data model.
NoSQL is built to allow the insertion of data in real-time, which gives application developers the ability to iterate quickly and build more powerful apps. Companies such as Google, Amazon and Facebook all use NoSQL databases to store user data and provide more personalized experiences to their users (at least, in theory. That's a debate for another day).
The main knock on NoSQL is that it lacks support from large vendors. This is somewhat true, although Amazon and Google have both launched their own NoSQL databases to work with their cloud storage products (DynamoDB and Cloud Datastore, respectively). To me, this proves that NoSQL is just as viable as SQL, if not more.
After working with SQL for the past week, I can't wait to dig into NoSQL. To me, NoSQL seems like a no-brainer to developing apps that scale and can be changed very quickly to support new features or enhance user experience. While I think there is certainly advantages to being forced into designing a schema before you begin development, I think it's more practical to allow for future changes. I think the key to developing an effective database is to combine principles from both technologies: try to plan your data model as thoroughly as possible before development begins and then iterate on it as fast as possible. Your database should be infinitely scalable to provide for the best user experience possible. In my mind, you really have one option: NoSQL.