Device Sync and Edge Server are Deprecated

MongoDB Atlas App Services & Realm
,
41

All the community can hope for now is to pressure MongoDB into open sourcing the backend. I don’t know if they’ll so quickly give away their paid product though, even now shuttering.

I’ll offer at least an alternative from my experience. I adopted Realm cautiously, to mitigate lock-in risk yes but also to protect my margins as a full-time indie dev.

I have app logic and UI across SwiftUI, in-app web views, and server-side with social/email auth. I store data on-device, in the backend, on iCloud, and inside transient in-app web views. I sync all of those in realtime. So let me share how I do it and what I can do to make this easier for the community by open sourcing more of it too.

On-device: local Realm

Backend: Django with Django-REST-Framework and a couple popular auth packages that give me batteries-included auth for email and social oauth. I run it on a $5 to $15 per month VPS on OVH Canada, because they have “unlimited” up/down monthly bandwidth (no risk of overage costs), and because Canada has easier worldwide compliance than US generally (apart from US-specific compliance needs that can happen in enterprise). I have Cloudflare in front of this and using Cloudflare Tunnels to avoid exposing to VPS to the internet at all via firewall, besides to Cloudflare. I wrote a realtime sync for Django models + a Swift client that is offline friendly. I could open source this if there’s interest in helping to make it more generic and reusable, because the approach is sound from my experience so far. It is pretty generic already but a bit hard coded to my specific models, though the approach is definitely generic and reusable.

iCloud: I made this iOS/macOS-friendly lib for syncing RealmSwift with iCloud / CloudKit: GitHub - lake-of-fire/BigSyncKit: Realm-specific fork of SyncKit to use IceCream's scalable approach to object subscriptions I’m using it in production with at least hundreds of thousands of rows per typical user.

Web views: I have RealmSwift syncing in real-time with web views (WKWebView) using RxDB: https://rxdb.info a JS DB with reactive hooks and realtime sync mechanism that I integrated. This lets me write app logic in any web tech (nice when I want to reuse on actual web deployment too later) or in native Swift as I like. The web views read and mutate user data via RxDB syncing back to Realm. I could also open source this, it mimics closely the realtime sync logic used in BigSyncKit above. I don’t need to pay for RxDB.

I would love to get help in extending and maintaining an integrated package of the above stuff if it would be useful for the community, since it’s so Realm oriented. It’s currently only helpful for iOS but the client logic could be ported and may have equivalent parts on other platforms too.

The above could be a valuable, basically free, open-source, and pretty straightforward transition for Atlas users. You can plug any DB into Django, not just SQL, there’s also some kind of MongoDB support, and there are a lot of batteries-included packages so it doesn’t require a lot of development and integration work.

The app I use the above in btw is Manabi Reader https://reader.manabi.io

3 Likes
42

Yes… I’m angry too. When MongoDB acquired Realm, I thought it was going to be a long-term solution. As an indie dev, time is limited for migration work.

I’ve already spotted some alternatives:

Hope they’ll offer some migration tips!

2 Likes
43

@Alex_Ehlke Great write up and a very generous offering. That certainly provides possibilities for sync and auth.

Here’s my concern - the core on device is still Realm, correct?

Without devolving into a rant…

We want a realistic (and stable) plan going forward for our projects but with a total lack of information and no participation from the Realm team I take a look at the business model:

The on-device database will continue to exist as an open source project

Realm has almost always been “open-source” but the purchase of it allowed a revenue stream to be generated by adding sync (so we can then pay for it).

It’s challenging for a business to dedicate resources to an “open-source” project that provides no revenue stream. They’re not going to do it out of the goodness of their hearts, right?

How would the business monetize that effort to offset the costs of maintenance, personnel, etc? Perhaps plug in some kind of advertising stream? I don’t know but the path is uncertain at this time.

My guess and gut instinct is it’s a “die-on-the-vine” strategy. Perhaps I am incorrect but my business revenue stream cannot sit and wait for some kind of direction/migration/anything! from this company which may never come.

So that was a small rant but end result is we will need to abandon this platform and seek other solutions for both on-device as well as sync/auth.

1 Like
44

Re: viability of local Realm… Personally I will monitor SwiftData for a few more years, and then transition to it another couple years after it’s matured. I already have a lot of Realm in my code that’s working well. I hope it can at least continue to run for another 5 years even if it’s not . I agree I’m suspicious that the community will be able to maintain it across the Realm Core and the many clients. But perhaps it’s able to maintain it enough that it continues to work without gaining new features, especially if we have methods such as mine for transitioning off Atlas and using it productively beyond simply local, working well enough to allow for a long multi year transition off it and to give people reason enough to continue using and keeping Realm local on life support.

But yes very sad, I’ve been using Realm for at least a decade.

45

Dear community members,

We understand that our recent announcement to deprecate services is raising some questions and some of our users will be meaningfully impacted by this news. We would like to reiterate our commitment to supporting you through the transition before the end-of-life (EOL) of these services in September 2025 to ensure the solutions you’ve built on our platform can continue to produce successful outcomes for you and your users.

The decision to deprecate those services was not taken lightly, but it will allow us to refocus our efforts on providing customers with a better experience with our other services and double down on our investments in the core database and other Atlas services.

Regarding the Atlas Device SDK. It consists of two parts: the on-device database and Atlas Device Sync. The on-device database will continue to be an open-source project. For the syncing, some of our partners, such as Ditto, are already working on integrations to make it easier for you to replace this SDK. Other partners also have similar offerings that integrate well with MongoDB (AWS AppSync, HiveMQ, Ably). A list of those alternative providers can be found at https://www.mongodb.com/docs/atlas/app-services/sync/device-sync-deprecation/.

Our team is dedicated to continuing to develop resources to help you navigate this migration process. In the meantime, if you need support along the way, you can contact our support team.

4 Likes
46

@Joel_Lord Thanks for the update. This is sad news even for local Realm as open source, because I don’t think it currently has much community contribution. So I would expect it to fall into disrepair immediately. Can MongoDB do anything else to improve the health of the project as open source?

47

WOW. we spent months migrating over and now its being deprecated… WTF… out of no where.

Can we at least prolong the deprecation time to 2-3 years… or offer a self hosting solution? Realm once provided a self hosted solution… before Mongo bought it and killed it.

5 Likes
48

@Joel_Lord, I think it is important to note that your offering of a migration guide is extremely thin. I migrated to MongoDB from Realm Self Hosted and the migration guide was well thought out and covered 90% of cases. Ian, Drew and others helped me migrate and I was so grateful. The “guide” that you have provided is a list of potential alternatives as you close the door on us. Ditto, HiveMQ and Ably are all more likely to be bought and deprecated or be out of business long before MongoDB and will prove to be a very risky move.

AWS App Sync is the only mentioned option that has some longevity potential, and in their post about using AWS App Sync with Atlas, they outline usage with the Data API which is also deprecated. (I posted about this above, but I understand that in your rush to put an end to the thread that you may not have read all of the posts)

There are no reliable options for sync that aren’t extremely risky.

Following your suggested alternatives as well as doing our own research has led me (and other developers) to realize that the following paragraph from your email is misinformed at best and egregiously dishonest at worst.

From our founding, our mission has been to simplify the world for developers when building applications. We create features where we see opportunities to streamline the developer experience and close gaps in the broader market. Since making these features, a rich ecosystem of open source and 3rd party technologies has emerged that offer solutions to meet these needs—including offerings from MongoDB’s ecosystem of more than 1,000 partners.

If you could get close to 1000 other options for device sync, I would be astonished. I doubt you could get anywhere near 100. So far you’ve offered 4. There is a giant hole in your story. The reason for deprecating these app services features is not because of the robust solutions at the ready for developers to use and has made app services obsolete. Without a clarification from Mongo, we must assume the reasoning is closer to maximizing share holder value, not simplifying the world for developers when building applications.

10 Likes
49

https://ditto.live, does look interesting and with good financial support. Pricing on their service on the other hand is ? and probably as unstable as the core product for edge cases and production

Wondering. How costly its going to be

50

It would have been better if the resources were completed and published before the announcement of the deprecated services. On using AWS AppSync as an alternative, someone here has pointed out that AWS’s post on using AWS App Sync requires using Data API which is deprecated.

2 Likes
51

So Realm was bouth to kill it - fine. Then please also give us the date when Atlas will be fully shut down so we can prepare in time (will be soon after next September anyway since the removal of those features is making it useless anyway).

3 Likes
52

Fair point @Kurt_Libby1. Even with the alternates that are being suggested, not even sure how long these would exist or when those would get deprecated. Even if the developers put in significant effort migrating to any of these services, there is a high chance that history would repeat and that they would be left stranded.

Checked out Ditto’s website, they are not even clearly mentioning how the pricing structure would be. They are asking people to develop a solution and when production ready, contact their team for pricing. Doesn’t really instill confidence does it?

6 Likes
53

Does the suggested Ditto alternative even work atm? I cannot find a single document explaining how ditto integrates with mongoDB in order to keep using Atlas.

EDIT: I see the answer above in the quote from Joel " For the syncing, some of our partners, such as Ditto , are already working on integrations to make it easier for you to replace this SDK."

So the answer is no. You guys have suggested Ditto that does not currently integrate with Atlas. You have suggested appsync which, as others said above, relies on another feature you have deprecated. You have suggested ably which only have live sync in alpha and that will only use postgres initially.

Does anyone have a serious suggestion?

6 Likes
54

Thankfully Couchbase has got your back, and honestly has been in market longest and still best among all.

4 Likes
55

Joel – I am sure my case is nothing special, but you need to realise all you have done is cost my company time and money.

We invested time to learn your tools, and have paid server costs. I feel lucky I haven’t launched yet, and I really feel for others. Thankfully we have the resources to move away from you.

But, yes, I’ve spent time and paid your company money, and in fact I’ve never put that work to a paying customer.

What do you offer me in return?

A year. Really!

If Ditto is so good, you should have completed the integration, have done the documentation and sold it to us. Work out a introductory deal with Ditto so we know what to expect. COMMUNICATE. Run DeviceSync as a legacy product for a sensible time to migrate customers. Reach out and talk to your customers. I can only think the migration path is not really there, or you just have so little respect for your customers you couldn’t be bothered. Neither sits well with me.

Instead, we have no migration guide, no transparent pricing. Oh yes, that sound like something I want to do right now – you have taken my database away and I really want a chat with a sales chap just to find out the pricing!

Utter joke.

We are as of yesterday testing other systems and will be migrating away as soon as we find something that fits our requirements.

To everyone else, good luck. I think quite a few of us are small companies and this is personally a hard pill to swallow. I really do wish you all well. Better things will come. Smile, the sun is still shinning.

Graham

9 Likes
56

The one-year timeline to rewrite our apps seems insufficient, especially considering that your recommended partner, Ditto is still in the process of developing integrations to facilitate SDK replacement. This ongoing development suggests that the migration process for your customers may be compressed to less than a full year once these integrations are complete.

Given these circumstances, would it be possible to extend the migration timeline?

3 Likes
57

@Joel_Lord It is very important the Data API and Custom HTTPS endpoints continue. Even if for realm and other products if we need to find an alternative, these 2 products are essential. These features are not seperate products but just connecting to Mongodb with Rest API. Alternatively at least have a Nodejs driver which works on Edge Functions of Vercel, Cloudflare, etc. This is extremely criitical. Please consider this at the least.

2 Likes
58

Dear MongoDB,

Our apps, built on these technologies, have had significant investments in both time and budget over several years.

A minimum end-of-life period of four to five years should be expected from a reputable company like MongoDB. This allows customers using your technologies to responsibly update their apps and move away from dependencies without jeopardizing their entire business.

Instead, you’re forcing us to pay for a rapid migration to suggested alternative solutions that don’t even exist.

MongoDB – do the right thing.

The consequences of this decision are alarming:

  • Many clients stand to lose 100% of their investment if they can’t afford migration, including the loss of customers and data.
  • One of the major reasons people discover MongoDB and use its database is that it’s a dependency for device sync and related technologies. There will be a severe reduction in future developers discovering, let alone using, MongoDB.

The reality is that there would be minimal cost for MongoDB to continue supporting Device Sync and other technologies. Yet the effective cost of choosing to deprecate it is astronomical for MongoDB’s brand and reputation. No wise CTO would ever choose MongoDB as a vendor unless MongoDB revises its stance and treats its developers and clients with respect for the trust placed in the company.

MongoDB – again - please – do the right thing.

Thanks,
Mark

14 Likes
59

I was just told by MongoDB Support, after asking for resources specifically for migrating to any of the alternative solutions, to contact the solution’s provider while the MongoDB team is working on improving and adding more information that pertains to the migration🫠

3 Likes
60

CoachBase with Capella looks like the way to go. 13 months ago, we decided to go with Atlass over Capella, and that decision has now come back to bite us big time.

4 Likes