RegattaDB linear scaling & no-compromise ACID in more detail

RegattaDB clusters scale from a single node to tens of thousands of nodes with hundreds of petabytes of data. Unlike traditional scale-out sharding, all of RegattaDB’s functionality - whether transactional or analytical - is always fully supported across the entire cluster, regardless of how data is distributed across the nodes.

RegattaDB’s groundbreaking ACID technology allows distributed transactions to reach the strongest-possible serializable isolation-level with full external-consistency . Those properties are guaranteed across the entire cluster and therefore a transaction could safely span multiple nodes. Unlike the industry’s traditional consensus that achieving distributed strong transactional semantics must come at the expense of performance, RegattaDB’s innovative concurrency-control protocol, in combination with its advanced distributed mechanisms deliver strong transactions in distributed clusters at high performance. RegattaDB’s performance is linearly scalable – i.e., the more nodes you add, the higher the transaction-rate is.

Strong ACID guarantees allow application developers to focus on business logic rather than on trying to accommodate for various failure scenarios and corner cases that are typical for databases that provide no or limited ACID guarantees, like for example eventually consistent databases or scale-out sharding databases that do not guarantee ACID across server boundaries across the entire cluster.

In addition, RegattaDB fully supports more relaxed modes of isolation, such as are typically offered by MVCC relational databases – e.g., Read-Committed and Repeatable-Reads with (or without) First-Committer-Wins check. RegattaDB’s isolation-levels can be set per-transaction, and transactions of mixed isolation-levels can run concurrently. Furthermore, high-performance bulk ingress operations can enjoy various consistency guarantees without compromising the ingress rate.

RegattaDB is designed to allow analytical activities to run alongside transactions. For instance, fully consistent read-only queries on real-time data can run efficiently without blocking transactions in any way.