SQL vs NoSQL

Key points from the ScyllaDB technical paper SQL to NoSQL: Architecture Differences and Considerations for Migration [PDF] - 

While RDBMSs are not fit for distributed deployments, non-relational databases are designed specifically to support such topologies.

A number of alternative non-relational database systems have been proposed, including Google’s Bigtable (2006) and Amazon’s Dynamo (2007). The papers for these projects paved the way for Cassandra (2008) and MongoDB (2009). 

Despite their origins in a long-forgotten technology cycle, relational SQL databases are by no means ‘legacy’ technology. Some SQL databases, notably PostgreSQL and MySQL, have experienced a recent resurgence in popularity. A new generation of NewSQL databases, notably Google Spanner and CockroachDB, leverage SQL as a query language and offer a distributed architecture similar to that of NoSQL databases yet provide full transactional support.

Relational databases are defined in part by their use of the Structured Query Language (SQL). In contrast, NoSQL databases employ a host of alternative query languages that have been designed to support diverse application use cases. A partial list includes MongoDB Query Language (MQL), Couchbase’s N1QL, Elasticsearch’s Query DSL, Microsoft Azure’s Cosmos DB query language, and Cassandra Query Language (CQL).

CQL is the most widely used NoSQL query language.

SQL vs NoSQL

While CQL is the primary language for communicating with Apache Cassandra, it is also supported by a range of familiar NoSQL databases. Common CQL-compliant databases include Scylla, DataStax Enterprise, Microsoft’s cloud-native Azure Cosmos DB, and Amazon Keyspaces. 

Rather than migrating an entire RDBMS to a NoSQL database, some applications benefit from leaving some data on a relational database, while moving a subset of data to a NoSQL database. A hybrid solution that spans two database types can offer the best of both worlds. For example, in some deployments, customer account information, which is infrequently updated, will be stored in an RDBMS, while transactional or streaming data, such as IoT sensor data or telemetry, might be stored in a NoSQL database.  Large, growing tables and storage for streaming data, especially in the context of event-driven architecture (EDA), are good candidates to migrate to NoSQL.  

SQL data models follow a normalized design; different but related pieces of information are stored in ‘relations,’ which are separate logical tables connected by joins. NoSQL databases use denormalized data models, in which redundant copies of data are added as needed by the consuming applications. The point of denormalization is to increase performance and lower latency since the joins involved in normalized data models can introduce significant performance overhead, especially in distributed topologies. 

When migrating from SQL to NoSQL, the primary key in the relational table  becomes the partition key in the NoSQL table. 

Tools like Apache Kafka can facilitate the process of migrating existing data from an RDBMS to NoSQL.

If your use case requires ACID guarantees, then NoSQL might not be an option.  Where the aggregate scale and speed of all transactions outweighs the specific correctness of any single query, then NoSQL is the best fit. 

Scylla, has been designed from the ground-up to overcome one of the key limitations of the first generation of NoSQL databases. Using a unique, close-to-the hardware design, Scylla combines the scale up capabilities of traditional RDBMSs with the high availability and resilience of non-relational databases. 

Also see - Can NoSQL replace SQL Server?