Skip to content


In the next set of chapters we will cover a number of very important concepts in RonDB. They are not absolutely necessary to understand RonDB from an SQL view, but it certainly helps to understand those matters when designing scalable applications using RonDB.

The first chapter is the replication protocol used in RonDB. It is based on the traditional two-phase commit protocol where we have made it a non-blocking protocol. It is also designed to handle predictable latency while at the same time providing a consistent recovery from cluster crashes.

Many new implementations of DBMSs have opted to use various replication protocols based on quorum and various forms of eventual consistency. In RonDB we provide strong consistency at scale to ensure that application developers do not have to worry about where to send their requests.

The next chapter shows how RonDB routes read and write requests. This is performed in a transparent manner to the application. But to design applications that scales to millions of transactions per second it is essential to understand this chapter.

The development of the cloud in various forms have made data center implementations streamlined such that clouds have several data centers per cloud region. We have designed features in RonDB that takes into account the placement of nodes within a region in a cloud. This ensures that we can improve scalability of cloud installations and also provide the optimal latency of queries executed in a cloud.

Any scalable DBMS will have to consider how the consistency of the data is handled. In RonDB we have designed for easy application development where applications can see their own writes and that the data is immediately visible. All consistency models have different advantages and disadvantages and in the chapter on Concurrency Control we describe how we handle this in RonDB.

The final chapter in this part goes through a feature that is currently unique in the MySQL world, the ability to parallelise query execution. This is a feature with many names, but it is about pushing down joins from the MySQL Server to the data nodes. In this chapter we describe how this is done and the advantages this provides and also the current set of limitations of this feature.