* SCALABILITY - Hypertable was designed for the express purpose of solving the scalability problem, a problem that is not handled well by a traditional RDBMS. Hypertable is based on a design developed by Google to meet their scalability requirements and solves the scale problem better than any of the other NoSQL solutions out there. * GOOD FIT FOR WIDE RANGE OF APPLICATIONS - Hypertable keeps data physically sorted by a primary key, it is well-suited to a broad set of applications. * COST SAVINGS - Hypertable has been designed and implemented for maximum efficiency and optimum performance. By choosing to do the implementation in a compiled language that does not incur the performance and stability costs of garbage collection and runtime interpretation, Hypertable can deliver equivalent database capacity on a fraction of the hardware. * PERFORMANCE - The other benefit of Hypertable's highly efficient design and implementation is that it delivers all the advantages you get from better performance. For live applications, Hypertable can help deliver a much more responsive user experience by reducing overall request latency. For offline applications, higher throughput is achieved which means more work can be accomplished in a given amount of time. * CLEAN SEMANTICS - Hypertable is a consistent database. Many of the scalable NoSQL database offerings are designed around the concept of eventual consistency which makes those databases more difficult to reason about. When an application writes data into Hypertable and gets a success response, the modification is durable and will always be reflected in subsequent operations.

* The Scylla row cache, unlike the original Cassandra cache, is designed to reconcile data in cache with incoming writes. Cassandra’s row cache invalidates the whole partition for a given table on write, but Scylla’s does not. The result is that Scylla can run mixed read/write workloads efficiently. This reduces the need for data model complexity that is only present in order to work around the Cassandra read-before-write problem. Reducing data model complexity can have the indirect result of saving storage bandwidth as well. * Scylla does not need to parse cached data from stable format to in-memory format before serving it, because the Scylla row cache already holds data in the needed format. * Scylla is a new approach to NoSQL data store design, optimized for modern hardware. The typical design of NoSQL data stores (left) consists of a JVM which runs on top of Linux, utilizes the page cache, and uses complex memory allocation strategies to “trick” the JVM garbage collector to avoid stop-the-world pauses. Such a design suffers from sudden latency hiccups, expensive locking, and low throughput due to low processor utilization. * ScyllaDB networking is designed to squeeze the most out of the hardware. No different from the other Scylla components, we optimize the hell out our CPU, our memory management and similarly, the network. Scylla supports two different networking modes—our own native Seastar network stack and the traditional Linux stack.