Provide Realm Sync as a paid service for users

Hi everyone, I’ve been using the Realm Database for a while and it really fits my need. But now I have a problem. As described in the title, I want to provide a paid subscription to allow users sync their data.

I want to achieve it by allow users pay for the service on the Gumroad and add a serial number to the custom user data. What I want to know is is there a way to prevent users without a proper SN from syncing the data?

In my understanding, the sync starts right after user login to the Realm app on the client side right?

Hi John, and welcome to the community! Sorry for the delay in replying; a lot of us have been out of the office around the holidays.

You’re correct about sync starting when you make a call to open the Realm. We’ll be adding some formal guidance to the documentation around this soon-ish, but the recommendation is to use local-only Realm Database for non-paying subscribers, and use a synced Realm for paying subscribers.

With the SN you propose as custom user data, you could use that to determine whether to use a synced realm or a local realm. If the user does not have a valid SN, open a local Realm Database. If the user does have a valid SN, open a synced Realm.

If a user subscribes to your paid service after using a local Realm database, you’d need to copy the contents of the local database to a synced Realm. Unfortunately, we don’t currently have a way to easily copy data between a local Realm and a synced Realm. On our page about adding Sync to a Local-Only App, we describe the process of copying data from a local Realm to a synced Realm. You’d need to manually handle this process. And the same thing goes in reverse, of course - if a paying user stops their subscription, you’d need to manually copy from the synced Realm to a local Realm database.

We are planning some enhancements that should hopefully make this process easier, which should be available later this year. Keep an eye on your preferred SDK’s release notes to watch for that.


Hi :slight_smile: Any update on when the enhancements will be released? I’m developing an invoicing app and pretty scared to go for Realm because of the risks of these manual migrations when user subscribe/unsubscribe… Is there example code in Kotlin of how you do the migration?

Thanks in advance

Hey there - we did add an API to our older Sync mode that enabled copying between a local and a synced realm, and vice versa. That API is not yet supported to copy data from a non-synced to a synced Realm that uses Flexible Sync. But the Kotlin documentation for this functionality is here:

Hi, thanks a lot for your reply!

If I understand correctly I have 3 choices if I want to sync data for users who pay for it, and without forcing sign-up for those who don’t. Please let me know if i’m missing something:

  • Save data with Local realm first, then manually migrate to Flexible Sync for users who subscribed to the feature. And vice-versa. If anyone has some feedback/code on this, i’d be interested…
    Also, do you have any rough idea of when the API will support to copy data from Local realm to Flexible Sync realm? Is it planned for 2024?
  • Save data with Local realm first, then migrate to the old Partition-based realm with the Realm.writeCopyTo() method. Then when copying data from Local realm to Flexible will be released, migrate Partition-Based Sync to Flexible Sync. It looks heavy though
  • Save data locally with Flexible Sync directly, using anonymous login to not force sign-up, keeping data only locally, then when the user pays for the feature, merge user identity and activate sync. The problem is that App Services Authentication provider deletes anonymous users after 90 days and data is lost, so another authentication system has to be used. Plus if the user is disconnected by one way or another, all data will be lost. Only solution would be to sync data for everyone, even the ones who didn’t pay…

Yes, your understanding is correct. I don’t know of a timeframe for this API to be available in Flexible Sync. You’re welcome to request this in the MongoDB Feedback Engine for Realm.

We don’t have a code example directly demonstrating how to iterate through all the objects in the realm and copy them into a new one. But we do have this higher-level diagram that walks through the logic involved:

We are generally not recommending that people create new Partition-Based Sync Apps at this time. It is our older Sync mode, and all of the new development for Device Sync is happening for Flexible Sync. So while your second option would work, we probably wouldn’t recommend it. The first option is currently our recommended approach.

1 Like

I extremely discourage doing anything with Partition Sync at all, you’re a lot better off going to Flexible Sync if anything. It resolves an enormous amount of problems associated to partition sync, and is a heavily more performant model in general.

As far as mapping data, I’m not on here to market myself but there are tons of people in general who can be commissioned to setup what you’re looking for with working logics.

But the blueprint Dachary posted is a great resource to map up, if this is something that continues to be a hard point in moving forward let me know and I’ll build a tutorial for it using Swift.

1 Like

Thank you for your replies, it’s very helpful.
Finally I think i’ll force sign up for everyone… because the risks of errors/data loss during local databases migrations (even when handled with the API) are triggering me :sweat_smile: I mean, i know that you delete the original db only when all records are saved in the synced one, and you can eventually relaunch it if it failed, but with Android and all its possible configurations, this is a wild world…

Obviously the ideal thing to preserve the local db would be:

  • that a Local db can be directly used as the local db of the Flexible Sync when schemas are similar - but I guess there’s a reason if it’s not possible?
  • even better: having a Flexible Sync mode “Local-only”, allowing to create a db without user account, and require an account only on sync activation… This is maybe something i can suggest in the feedback page? or does it seem inconceivable?