The NoSQL solutions were primarily about getting rid of structure. Part of the power of relational database systems is the "relational" piece. There are strict and governed relations within the database that are embodied in the schema. You aren't allowed to write arbitrary data into a relational database -- it has to fit properly into the schema -- and the database software will deny the attempted write if it doesn't fit properly.
The primary need of the NoSQL crew was to collect all the data that was being generated by and collected about their users, regardless of the type of data. They didn't want to be encumbered by schema, at least not when the data was being written ("schema on write").
In order to analyze the data, you do need to know what and where the data you are trying to analyze is. NoSQL solutions in effect defer the schema question -- they are happy to try to figure out the schema of the data when they get around to analyzing it, that is when they read it out ("schema on read") rather than when writing it. So not only do they not need to get all the interested parties to agree on what the data is and where it fits ahead of time, it provides flexibility in allowing all those parties to view the data differently when they want to consume it.
NoSQL creators started with a clean whiteboard -- throwing out everything about relational databases including the popular Structured Query Language, which is used to access data in a relational database. They soon realized that most of their prospects had lots of business analysts who knew SQL but didn't know Java, Python, R, or other new programming and analytical languages so by removing SQL, they considerably limited their potential users.
Most NoSQL vendors have come to realize this was a mistake so they have added SQL or SQL-inspired functionality and access. NoSQL is no longer a movement inspired by rejection of SQL (No SQL) but is now more accurately described as more inclusive of SQL (Not Only SQL). Many, but not all, of today's leading NoSQL tools offer SQL or SQL-inspired functionality.
Around the time that the NoSQL solutions were being developed, a different group of researchers and developers were taking a different tack. Instead of throwing out everything about relational database systems, they examined traditional RDBMS architecture and processing to try to figure out what prevented it from scaling to higher numbers of users and higher performance.
People like Mike Stonebraker, VoltDB’s co-founder and the creator of some of those traditional systems like Ingres and Postgres, were able to identify those limiting characteristics and to effectively remove them. This provided the benefit of being able to create a highly performant, highly scalable database that maintained some of the key benefits of traditional relational databases, things like full ACID compliance and transactions, SQL language support, etc. These new SQL-based systems were collectively called NewSQL.
Ultimately, the trend towards blurring SQL and NoSQL technologies is an improvement over many first-generation technologies. Fast data demands the ability to query assets in real-time. While in many ways some of the initial, key differences between these technologies have faded, each offers distinct advantages and disadvantages. Join us as we review the state of SQL, NoSQL, and NewSQL, and why each could be right for you.
SQL is a standard language used by developers, DBAs, and business analysts to query data sets. Traditional SQL databases offer rich transaction capabilities, ad-hoc query and reporting capability, and vast amounts of standards-based tooling. Where they fall short is in the ability to scale out to meet the needs of modern, high-performance applications.
NoSQL was a solution to issues of scale that emerged as organizations began dealing with immense volumes, velocity, and variety of big data from a multitude of sources. NoSQL solutions offered availability, flexibility and scale. However, they came with difficult tradeoffs - sacrifice of data consistency and transactional (ACID) guarantees, loss of ad-hoc query capability and increased application complexity. Trading off data consistency and ACID in many cases means application developers, who are not distributed data infrastructure experts, have had to try and fill the gap.
NewSQL attempted to do what NoSQL did without those tradeoffs. By removing just the parts of SQL that hampered scalability and performance, it was able to increase both while maintaining key advantages of SQL systems.
NewSQL technologies offer the best of both worlds: the scale of NoSQL with the ACID guarantees, strong consistency, minimized application complexity and interactivity of SQL.