Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC
This paper presents a controlled benchmark comparing REST polling, WebSocket push, and CockroachDB CDC architectures for real-time database synchronization, revealing that while WebSocket push offers the lowest median latency and REST polling provides predictable bounded delays, CDC delivers competitive medians but suffers from significant tail latency due to batching and specific protocol incompatibilities.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
In the world of modern software, there is a growing desire for applications that feel like they live on your device, even when you are not connected to the internet. This approach, often called local-first software, allows you to edit a document or update a list while offline, with the changes waiting to be sent to a central server once your connection returns. The challenge lies in the moment the connection is restored: how does the computer decide which version of the data is correct, and how quickly can it update the central server without the user waiting? For this to work smoothly, the system needs a reliable way to listen for new information and deliver it instantly. If the update is too slow, the user feels a lag; if the system is too complex, it drains the battery or crashes. The core question for engineers is how to build this listening mechanism: should the device constantly ask the server if anything has changed, should the server shout the changes out immediately, or should the database itself keep a running log of every action to be read later?
A researcher at the Indian Institute of Technology Kharagpur set out to test these three common strategies side-by-side to see which one actually performs best in a controlled environment. The study compared a method where the client checks for updates at fixed time intervals, a method where the server pushes changes instantly over a permanent connection, and a method where the database streams a log of every change to subscribers. To ensure a fair test, the researcher built three separate systems that looked identical to the user but used different internal gears. One system used a standard database with a simple "check-in" loop. Another used the same database but added a trigger that fired a signal the moment a change happened. The third system used a different, distributed database that was designed to stream its own history. The goal was to measure the exact time it took for a change made by a user to travel through the system and appear on the listener's screen, testing everything from a single user to fifty users writing at the same time.
The results painted a clear picture of how each method behaves under pressure. The system that relied on the server shouting changes instantly via a permanent connection proved to be the fastest. In the best cases, a change appeared on the listener's screen in just two milliseconds, and even when fifty people were writing at once, the delay rarely exceeded sixty-three milliseconds. This method kept its speed remarkably steady, with the slowest updates still arriving in less than a quarter of a second. The method that relied on the client asking for updates every hundred milliseconds was predictable but slower. Because the client had to wait for its turn to ask, the average delay was around sixty milliseconds, but it could never be faster than the time between checks. When many users wrote at once, this waiting time grew, pushing the average delay to over one hundred milliseconds. The system that used the database's internal log of changes showed a mixed performance. While the typical update arrived quickly, often in under a second, the system suffered from severe delays for the slowest few updates. Occasionally, a change would take more than two seconds to arrive, and in some cases, the delay stretched to over three and a half seconds.
The researcher discovered that the slowest updates in the log-based system were not a flaw in the idea of logging changes itself, but a result of how the specific software was connected. The system used a workaround to read the database log because the standard connection tool did not speak the database's language correctly. This workaround required starting a new process every time the connection was interrupted, which added a heavy penalty of one to four seconds to the delay. Without this specific technical hurdle, the log-based method might have performed much better, but in this test, the long delays made it unsuitable for applications where users expect instant feedback. The study also confirmed a simple rule for the checking method: the longer you wait between checks, the longer the average delay becomes. If a system checks every fifty milliseconds, the average wait is about thirty-six milliseconds; if it waits five hundred milliseconds between checks, the average wait jumps to over three hundred milliseconds.
These findings offer a practical guide for building software that needs to stay in sync. For applications where speed is critical, such as collaborative editing tools where users type together in real time, the method where the server pushes changes instantly is the clear choice. It offers the lowest delay and the most consistent performance, even when many people are using the system at once. The method where the client checks for updates at regular intervals is a solid option for simpler applications where a delay of a few hundred milliseconds is acceptable, or where keeping the connection open is difficult, such as on mobile devices trying to save battery. The method that streams the database log is powerful for moving large amounts of data or creating backups, but the specific implementation tested here was too slow and unpredictable for interactive use. The study concludes that while all three methods work, the best choice depends entirely on whether the priority is instant responsiveness or operational simplicity.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.