The checkpoint carries this design. A snapshot in R2 is a checkpoint number, a createdAt timestamp and a record set, and the client stores that checkpoint after importing the data [12]. It then asks the sync layer for everything after it [6]. That holds only if the snapshot job and the sync endpoint agree on what the number counts, because one coordinate is doing two jobs: marking where the bulk import stopped and where the incremental pull starts [12]. Misalign them and you write gaps or duplicates into the local database your reports are computed from.
The arithmetic in the post is illustrative, and worth doing anyway. A snapshot at checkpoint 98,000 against 100,000 records means 98 percent of the history arrives as one object from R2 and 2 percent arrives as a delta [11][1]. The example rate, 100 transactions a day for 1,000 days, is about two and three quarter years of accumulation [10][2]. The real application takes hundreds a day [1], so at 300 a day the same 100,000 rows land in roughly 333 days [3], and a weekly snapshot leaves about 2,100 records for the first incremental sync to walk [4]. Snapshot frequency, not RxDB, sets first-load cost.
It sets read cost too, in the direction people forget. The post does not state the cadence or how the snapshot is produced [16]. If it is produced by reading current state out of D1, then under rows-read billing [4] the full scan you deleted from every report has become a full scan on a schedule, and the bill tracks cadence [5]. That is a good trade when many users run many reports over the same history, and a bad one if you snapshot hourly for three people.
The conditions for transfer are narrow. Every client has to be entitled to the entire reporting dataset, since the snapshot shown is a bare record array with no per-user filtering described [17]. Devices have to store and query that dataset, which the author treats as reasonable precisely because the application is internal with few users [15][13]. And your reads, not your writes, have to be the thing that hurts [2]; D1 was fine for the transactional side [1].
The part worth stealing is the discipline of one checkpoint. The snapshot is not a parallel export with its own semantics; it is the sync stream materialized at a point the sync protocol already understands [12], which is why bootstrapping a new device is a download plus a delta instead of a special code path. RxDB supplies local persistence, reactive queries and synchronization [9]. The interesting engineering is in the coordinate the two paths share.
