The core of cr-sqlite drops metadata aggressively to keep DB size down, even when offline for prolonged periods of time or doing thousands of writes per second.
The basic idea is that the network layer would package changes from last_seen db_version to current db_version in a single block and peers would write that block in a single transaction.
Blocks can be as small as a single db_version or as large as the user wants, so long as:
The entire block is applied at once
Blocks are applied in-order
If blocks have not been sent to a peer yet, they can be merged together to save space. There is a balance here between:
The core of cr-sqlite drops metadata aggressively to keep DB size down, even when offline for prolonged periods of time or doing thousands of writes per second.
This choice, however, impacts how transactions are synced (documented here: https://vlcn.io/blog/how-crsqlite-transactions-work-today) but users can maintain transactional sync in the network layer if desired.
The basic idea is that the network layer would package changes from
last_seen db_versiontocurrent db_versionin a single block and peers would write that block in a single transaction.Blocks can be as small as a single db_version or as large as the user wants, so long as:
If blocks have not been sent to a peer yet, they can be merged together to save space. There is a balance here between: