Benchmarking Real-Time Database Synchronisation Architectures: REST Polling, WebSocket Push, and CockroachDB CDC

<title>Abstract</title> <p>Local-first and offline-first applications require efficient mechanisms to syn- chronise a client-side data store with a central server database. Three dominant architectures have emerged: (A) REST polling, where clients periodically query a /poll endpoint for changes; (B) WebSocket push, where the server broadcasts changes in real-time via PostgreSQL LISTEN/NOTIFY triggers; and (C) Change Data Capture (CDC), where the database replication log streams mutations to subscribers. We present a controlled benchmark comparing these three architec- tures under identical experimental conditions. Each is implemented as a FastAPI server; Architectures A and B use PostgreSQL, Architecture C uses CockroachDB v26.2. We measure end-to-end synchronisation latency—from write dispatch to listener receipt—across five concurrency levels (1, 5, 10, 25, 50 concurrent writers) with 80 operations each, using three independent trials for Architectures A and B. Critically, Architecture A uses a properly independent 100 ms polling loop, not a trigger-based approach. WebSocket push achieves the lowest median latency (P50: 2–63 ms), REST polling delivers bounded latency (P50: 61–141 ms, consistent with the 100 ms polling interval), while CockroachDB CDC shows competitive median performance (P50: 23–94 ms) but very high observed P99 tail latency (2.2–3.6 s) due to changefeed batching. A REST poll-interval sensitivity experiment shows an approximately increasing relationship between poll interval and latency. We also document a protocol incompatibility between asyncpg’s extended query protocol and CockroachDB’s changefeed cursor semantics, and provide a subprocess-based workaround.</p>