NoSQL vs SQL vs NewSQL

What to consider when building out architectures

SQL Databases

"SQL" is used both as the name of a language and a type of database. SQL, the language - structured query language - is designed for managing data in relational database management systems (RDBMS). Relational database management systems are often called SQL databases since they use the SQL language. Since the mid-1980s, SQL has been a standard for querying and managing RDBMS data sets. 

Relational databases continue to provide the foundation for the world's transactions. Think about all the credit card transactions being handled by the mainframes and large UNIX servers in the data centers of financial services companies. Web-scale proved to be a great challenge to those traditional RDBMSs -- you couldn't build a single shared resource machine big enough to handle the demands.

SQL features

  • Rely on relational tables
  • Utilize defined data schema
  • Reduce redundancy through normalization
  • Support JOIN functionality
  • Engineered for data integrity
  • Traditionally scale up, not out
  • Rely on a simple, standardized query language
  • Near universal in adoption

NoSQL Databases

While NoSQL technologies have existed for decades, they didn't gain popularity until the early 2000s as organizations sought solutions to house massive quantities of big data at rest more cheaply than they could with RDBMSs and then to be able to handle the higher and higher velocity of incoming data.

While a SQL database is a defined, concrete concept, NoSQL is not. There is enormous variation in technologies that fall under the NoSQL category (though they generally share some characteristics). Thus, NoSQL is a term used for a broad group of data management technologies which vary in features and functionality but which try to solve some key issues of SQL databases.

NoSQL features

  • High performance writes and massive scalability
  • Do not require a defined schema for writing data
  • Primarily eventually-consistent by default
  • Support wide range of modern programming languages and tools

Why NoSQL

NoSQL began as a movement to replace relational databases for specific needs, particularly for gathering and storing massive amounts of data, like all the web activity data of users of sites like Google, Twitter, LinkedIn, and Facebook. Hadoop came out of Google's need to compute page rankings. There were no transactions going on -- just collecting and consolidating massive amounts of data on page links.

Google could easily jettison most of the historical relational database model since little of it was needed for their use case. They wanted to store terabytes and then petabytes of data, cheaply and easily, and be able to run batch analytics on all that data.

Likewise, other large web-based companies discovered that traditional transactional systems had too much baggage and offered too few benefits for their particular and distinct use cases. So were born the progenitors of NoSQL systems such as MongoDB, Cassandra and Redis.

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.

Characteristic SQL NoSQL NewSQL
Relational Yes No Yes
SQL language support Yes No* Yes
Fully ACID Compliant Yes No Yes
Horizontal Scalability (Scale-out vs. Scale-up) No Yes Yes
High Performance No Yes Yes
Schema-on-Write Yes No Yes

*For more on how NoSQL and NewSQL stack up, including specific use cases and decision trees, we recommend NoSQL vs. NewSQL: Choosing the right tool

SQL or NoSQL: Which is Right for You?

Need NoSQL SQL
Do you want a relational database? No Yes
Do your records have consistent properties? No Yes
Is your data highly variable in structure? Yes No
How would you like relationships captured? Denormalization into single records Joins
Is your data structured? Sort of Yes
How are your schemas? Dynamic, flexible or non-existent Consistent
Do you require ACID transactions? No Yes
How important is consistency? Varies according to solution Strong support for consistency
How would you like to scale? Horizontally Vertically (SQL), or horizontally (NewSQL)

Which of the Fastest SQL & NoSQL DBs is Right for your App?

If you think SQL technologies are rigid or difficult to scale, you haven't met VoltDB. It offers all of the "best of both worlds" options of NewSQL technologies, making it faster and smarter than traditional SQL and much simpler and more accurate than NoSQL technologies.

The unique in-memory scale-out architecture enables 100x faster performance than traditional alternatives. This enables our customers to convert live data into business value, analyze and act on streaming data, and make use of real-time intelligence.

With VoltDB, data is always consistent, always correct, and never lost. Seamless integration with the full data management ecosystem (including Hadoop, Spark, Data Warehouses, Kafka), simpler application development, easier testing, and familiar SQL interactivity offer an integrated high-throughput, low latency system-of-record for data-intensive applications.

VoltDB offers customers:

  • The world's fastest in-memory operational database
  • Fully ACID compliant -- data is always correct
  • Supports ANSI SQL
  • Full persistence, Intra-cluster and Cross data-center replication -- data is never lost
  • Per-event transactions on live streams of data

Is VoltDB right for your application? VoltDB is the most enterprise-ready, proven NewSQL offering. It combines streaming analytics, strong ACID guarantees, familiar SQL data interactivity, and native clustering. For applications that require fast decisions on live streams of data with the speed of NoSQL and strong consistency, it's the right choice.

ipad-3.png

VoltDB Alternatives

Wondering how VoltDB compares and even compliments various alternatives? We've got you covered.

Learn More