SQL vs NoSQL

Very often, today’s cloud services and applications will start out with just a few requests and a very small amount of data. These can be served by just a few nodes. But if the application becomes popular, they would have to scale out rapidly in order to handle millions of requests and many terabytes of data. YugabyteDB is well suited for these kinds of workloads.

Here are a few different criteria where YugabyteDB brings the best of SQL and NoSQL together into a single database platform.

These can be loosely defined as the high-level concerns when choosing a database to build an application or a cloud service - such as its data model, the API it supports, its consistency semantics and so on. Here is a table that contrasts what YugabyteDB offers with SQL and NoSQL databases in general. Note that there are a number of different NoSQL databases each with their own nuanced behavior, and the table below is not accurate for all NoSQL databases - it is just meant to give an idea.

Operational characteristics

Operational characteristics can be defined as the runtime concerns that arise when a database is deployed, run and managed in production. When running a database in production in a cloud-like architecture, there are a number of operational characteristics that become essential. Operationally here are the capabilities of YugabyteDB compared to SQL and NoSQL databases. As before, there are a number of NoSQL databases which are different in their own ways and the table below is meant to give a broad idea.

Core features

Applications and cloud services depend on databases for a variety of built-in features. These can include the ability to perform multi-row transactions, JSON or document support, secondary indexes, automatic data expiry with TTLs, and so on.

Here is a table that lists some of the important features that YugabyteDB supports, and which of YugabyteDB’s APIs to use in order to achieve these features. Note that typically, multiple databases are deployed in order to achieve these features.

High performance

YugabyteDB was built with a performance as a design goal. Performance in a public cloud environment without sacrificing consistency is a serious ask. YugabyteDB has been written in C++ for this very reason. Here is a chart showing how YugabyteDB compares with Apache Cassandra when running a YCSB benchmark. Read more about the .

The first chart below shows the total ops/second when running YBSB benchmark.

The second chart below shows the latency for the YCSB run.

Because of this configuration, this universe can:

• Allow low read latencies from any region (follower reads from a nearby data center)
• Allow strongly consistent, global writes
• Survive the outage of any region

The graphs above, also taken from the EE, show that the average read latencies for apps running the the various cloud regions are just 250 microseconds, while writes are strongly consistent and incur 218 milliseconds.

Multi-cloud ready

It is possible to easily configure YugabyteDB EE to work with multiple public clouds as well as private data centers in just a few minutes.