Hypertable was designed for the express purpose of solving the scalability problem, a problem that is not handled well by a traditional RDBMS. While it is possible to design a distributed RDBMS system by breaking the dataset into shards, this solution requires an enormous amount of engineering effort and the resulting system will have inherent weaknesses because the core database engine was not designed for scalability. 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
Many of the current scalable NoSQL database offerings are based on a hash table design which means that the data they manage is not kept physically ordered by any meaningful key. These systems do not lend themselves well to applications that require fast access to ranges of data (e.g. analytics, sorted URL lists, messaging applications, etc). Because Hypertable keeps data physically sorted by a primary key, it is well-suited to a broad set of applications.
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. This translates into less equipment, less power consumption, and less datacenter real estate.
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.
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. Eventually consistent databases require complex syntactic or semantic reconcilers and in some circumstances can even lose data. When an application writes data into Hypertable and gets a success response, the modification is durable and will always be reflected in subsequent operations.