Skip to main content
This content is for SDK V4. For the latest version, see the V5 documentation.
This feature is available in SDK version 4.12.0 and later.
Every data modification in Ditto returns a commit ID that you can use to track when that specific commit reaches other peers in your mesh network. To check whether a local write has synced, you combine two values from two different sources:
  • The write’s commit ID. Every INSERT, UPDATE, or DELETE returns a commit ID on its QueryResult (for example, result.commitID). SELECT statements do not produce a commit ID.
  • The peer’s synced_up_to_local_commit_id. Query the built-in, local-only system:data_sync_info collection to see the highest local commit ID that a given peer (for example, the Ditto Cloud server) has confirmed. A SELECT against system:data_sync_info never returns your write’s commit ID; it only reports how far each peer has caught up.
If synced_up_to_local_commit_id for a peer is greater than or equal to your write’s commit ID, that write has reached that peer.

What Are Commit IDs?

Commit IDs are unique, monotonically increasing identifiers assigned to each data modification on your device:

Key Properties

  • Monotonic - Always increasing (1547, 1548, 1549…)
  • Device-specific - Each device has its own sequence
  • Per-operation - Every INSERT, UPDATE, DELETE gets a new ID
  • Trackable - Use with system:data_sync_info to monitor sync progress

Tracking Sync Progress

Compare your commit ID with synced_up_to_local_commit_id to see if peers have received your commit:

Monitoring Multiple Commits

Observers on system:data_sync_info trigger the callback on a fixed 500ms interval, regardless of whether the underlying data has changed.
Track several commits and watch them sync in order:

Transaction Behavior

Commit IDs are only assigned after transactions complete:

Checking Specific Peers

Track sync progress to any peer (not just cloud servers):

Best Practices

Remember that Ditto is offline-first. Use commit ID tracking to enhance user experience, not to block operations.
  • Don’t block operations - Let users continue working while tracking sync in background
  • Show progress indicators - Use commit tracking to display sync status in your UI
  • Handle concurrency gracefully - Tracking should enhance the experience, not block it
  • Monitor critical data - Focus tracking on important operations like payments or submissions
  • Clean up tracking - Remove old commit IDs from your tracking lists to avoid memory issues