Introduce sync frequency threashold


I’m trying to optimize the number of changeset requests sent by my mobile app. I, of course, try to use as much write batching as possible and optimize app logic, but wondering if there is a way to tell Realm to batch changesets and set them upstream, say, no more often than every minute or maybe even triggered manually? This way I could rate limit requests for free users and enable real-time sync for paid users.

I was able to achieve it by using:


I paused sync and did a bunch of actions in my app. Then resumed and checked out Atlas logs, it clearly has batched everything into a single request. But this approach feels a little bit hacky. Can anyone help me out here, is this the only way, or maybe there is a better option?


Hi @TheHiddenDuck,

The approach you mentioned will indeed batch more changesets into an upload message, but I’m interested in what you’re trying to achieve? In general, keeping the sessions active will reduce load on your cluster by reducing the amount of “catch-up queries” the sync service needs to perform when a client connects after being offline for some time.

Also note that if this is for the purposes of billing, uploads are billed per realm transaction, not per upload message. So batching will not reduce the number of billing requests.

Hello @Kiro_Morkos . Thank you for your reply. I am trying to optimize for billing. I have checked the documentation and it says:

Sync Operations , such as when a sync client uploads a changeset, when App Services resolves a conflict in an uploaded changeset, or when App Services sends changesets to a connected sync client.

so I assumed each uploaded changeset is a single billable request. Is that not so? So, for example, if I execute 10 write transactions while offline, and they get uploaded in a single changeset, will I be billed for one request or for 10?

A changeset is 1-1 with a realm transaction, so 10 write transactions will generate 10 changesets. How they are batched for upload is an implementation detail that will not impact billing.

I see. Thank you, this is helpful. I was confused by the fact entries in Atlas logs always looked like a single batched transaction for all entities I inserted/updated.

So does this mean that the only way to optimize for cost here is to try to batch as many changes as possible into single transactions and not have 1 to 1 mapping between, say user switching a toggle in preferences and a Realm transaction?

That’s correct. Although you should keep in mind the best practices for realm transactions. A realm transaction is an atomic unit of work and should be kept small in order to avoid hurting performance or encountering issues with sync.

Hi, good chat.

I think the real problem of SYNC cost is they charge by user connected time. If user is logged all day and no data is update, charge will occur.

Formula: (# Active Users) * (Sync time (min / user)) * ($0.00000008 / min)

Old thread Session.Stop() stop Billing?

Hm, that wasn’t a big concern of mine. In my app, I pause/resume sync when the app is backgrounded/foregrounded, so the numbers I got for this are kind of minuscule for my amount of users and their usage patterns, but requests can add up very fast.