Updated: 2024-09-17
The first thing I ask a customer when I meet them is "Why did you choose PowerSync versus other options?". On a call last week with a CTO of a tech company in the construction sector, the answer to that question was "I wanted to use Atlas Device Sync but MongoDB told me they have decided to EOL it".
I nearly fell off my chair at first — I've been following the situation with Realm Sync very closely over the years and always viewed it as a fantastic product. In fact we originally considered building PowerSync on top of MongoDB, but we decided against it because Realm Sync was on the market. This kind of news is every developer's worst nightmare and we were still trying to figure out what this meant for PowerSync when MongoDB went public with the news.
Developers are now faced with a couple of options:
- 1. Migrate to a different sync engine, which requires moving off of MongoDB entirely
- 2. Stay on MongoDB
- 2a: Build your own sync engine
- 2b: Implement custom data pipelines with PowerSync
- 2c: Hope that someone comes up with a drop-in migration path
- Update 2024-09-17: PowerSync is now working on a drop-in migration path. Details here.
In this post, I’ll shed some light on the above options — here at PowerSync we can help with options 1, 2b and 2c.
Option 1: Migrate to a different sync engine
Unfortunately there’s not much on the market at the moment that plugs into MongoDB, so most of these options involve moving off of MongoDB.
PowerSync is a good option if you can move to Postgres since it’s architecturally quite similar to Atlas Device Sync and Atlas Device SDK:
On the client-side, this will require moving away from Realm to SQLite, since that’s what the PowerSync client SDKs use under the hood. We may investigate adding Realm support on the client in the future, but have no current plans to do that.
We’ve been speaking to multiple users who have decided to take this path, some eager and some reluctant.
Users that aren’t already running Postgres need to decide between using a hosted Postgres provider or hosting Postgres themselves. We can highly recommend taking a look at Supabase (either hosted or self-hosted) as a great way to introduce Postgres to your stack.
PowerSync Compatibility Checklist
- Can you add Postgres to your stack?
- If you plan on using a hosted Postgres provider, do they support creating logical replication publications? This is required by PowerSync: here is a list of supported providers.
- Does PowerSync have a client SDK in your language of choice? Here is the list of supported clients.
Other options are AWS Amplify AppSync (although we’ve heard rumors that they are decommissioning their Amplify DataStore in the generation 2 backend) and ElectricSQL (not production ready yet, comparison blog post here). For a more extensive list, see Section 2 (“Build”) here.
For customers that need to stay on MongoDB, options 2a through 2c are discussed below.
Option 2a: Build your own sync engine
For some very basic use cases, this could be feasible and there are some good tools on the market here such as TinyBase, WatermelonDB and Replicache. Replicache would require moving off of MongoDB, but you can build your own sync engine using WatermelonDB or TinyBase.
Option 2b: Custom data pipelines with PowerSync
Customers on our Enterprise plan can use PowerSync in conjunction with custom data pipelines. The solution architecture would therefore look like this for downloading data from MongoDB into the PowerSync client SDK:
And like this for uploading data, where the “Backend App” can be your existing backend or potentially needs to be a new app (but it can be very thin):
Note: we originally wanted to include Ditto as an option here, but as far as we can tell it’s not a practical option:
Option 2c: Hope for a drop-in migration path
Update 2024-09-17: We have taken the PoC mentioned below further and are nearly ready with an alpha release that customers can test. Please follow progress here.
We are currently investigating what we can do here to help users with this option. We have implemented a working PoC of MongoDB-based replication and are analyzing what it would take for us to implement a stable version that customers can use. It’s possible that we will release something in 2024 that would be a drop-in replacement for Atlas Device Sync on the server-side.
Vote on our roadmap for MongoDB here to stay subscribed to updates.
More to come
In the coming days and weeks, we plan on updating the above blog post as more information and options become available.
