Speaking for ObjectBox, I think your approach should fit very smoothly. ObjectBox uses plain objects - so “loading data into memory” is already done. Usually there’s little need to have an abstraction onto that as it would imply copying an object from one class to another class that basically looks the same. But of course for the sake of a full abstraction you can do that; e.g. maybe you want relations to work a specific way.
For Sync, ObjectBox does not differentiate between storing objects in the local database and syncing these objects. But if you wanted, you could have a local DB and separate synced DB. It feels odd on a first glance to me though…
Has anyone looked at powersync to determine if its a viable alternative for the device sync aspect? I was only using atlas cloud and realm because I had no choice. What I need a solution to is the sync and happy to swap out the rest.
Would add the same clarification to Bryan, that Ditto is unique in that it can sync P2P, but syncing from a mobile client to a server is also part of the platform. Here is a helpful diagram:
What is unique to Ditto is you can have both (if you want). Devices that are “offline” in a traditional sense because they lost touch with the server can communicate through other Small Peers and keep syncing with the server (Big Peer). However, if this is not valuable you can just disable the P2P and you are left with the same query-base realtime sync from edge to cloud like Device Sync.
Love the feedback and thoughts. However, I would like to clarify that Ditto is a platform that does P2P and edge to cloud. We call our SDKs - Small Peers because they can connect P2P, but you can also disable that too. Our server is called Big Peer and Small Peers connect to it when they can syncing just like Device Sync. In this case, yes you can use Ditto as a replacement.
Your points on ergonomics are valid. We started with a more Realm like APIs but again to the point on pragmatism, supporting N of SDKs with custom APIs is a massive challenge and our customers tend to use multiple APIs, so a common query language across backend and multiple front end apps was more important. Ideally this is temporary and we add more sugar on top as we grow, but I can appreciate its not as elegant than Realm.
PowerSync is a server<–>client sync solution that keeps an on-device SQLite database in sync with a backend database.
Based on the situation here, we have fast tracked support for MongoDB on the backend. It should enable customers to continue using MongoDB (Atlas or self-hosted) as a “drop-in” sync solution for the most part, with the bulk of the migration work required being on the app side since you need to move from Realm to SQLite (we don’t plan to support Realm just yet but nothing prohibits us on a protocol level).
We have some docs here and will keep everyone updated - let me know if you’d like to test our MongoDB support once it’s available (ETA next week).
Thanks for the info Kobie. If you don’t mind answering another question. My app is an Android Kotlin Native application. I see that there is a KMP SDK for powersync without JVM support. And the kotlin native SDK is in the “under consideration” section of your roadmap. Would I be correct to assume that my application would not currently be able to use powersync?
@Kobie_Botha My team is a little unclear on this from your migration documentation:
Spin up an instance of the PowerSync Service and connect it to your MongoDB database
Can you provide some clarity on what “connect it” means or what that process is? Our interface to MongoDB Atlas is (was) through the SDK’s, CRUD/App Services. That’s going away. What are you doing to talk to “our database”
And this this part from your above post
move from Realm to SQLite
We don’t think that’s a drop-in as that’s essentially an app re-write since we’d be moving from Objects and filters/type-safe queries (in Swift at least) to SQL string based selects/inserts/updates. Or am I missing something (which is highly likely lol).
And the kotlin native SDK is in the “under consideration” section of your roadmap.
That was actually a state management issue - it was marked as planned internally but the portal state was wrong. I’ve moved it to planned now. Thanks.
Would I be correct to assume that my application would not currently be able to use powersync?
As it stands today that is correct, but IIRC it’s not a huge project for us to support Kotlin Native. Does PowerSync check all the other boxes for you?
Can you provide some clarity on what “connect it” means or what that process is?
You’ll need to provide a MongoDB database user to the PowerSync service that can be used for sync. We’re still documenting the exact permissions required by this user.
What are you doing to talk to “our database”
Not sure I fully understand the question. Are you asking how the connection works or are you asking on a more functional level why the connection is required?
We don’t think that’s a drop-in as that’s essentially an app re-write
Yeah I agree - by drop-in I meant on the server-side. You wouldn’t need to migrate off MongoDB. As I mentioned the bulk of the migration work will then be moving off of Realm on the client.
PowerSync would be our top candidate if it had a Native SDK. Is there timeline for when this could be at beta stage? Even though there is a year until deprecation, we can’t wait a year to begin the huge work of overhauling our cloud db/sync to replace what’s been lost.
Pardon our lack of knowledge on the server side of things: yes, how does that connection work. In other words, in one decision, several hundred developers were cut off because the tools we need were all depreciated.
Your diagram has a green box “PowerSync Service” that sits between MongoDB and the PowerSync SDK. With all that’s happened what’s to say that “connection” will not be depreciated as well?
The source code for that sync service is open and free to use forever, so worst comes to worst you can always self-host that part. Repo here. Blog post here.
Our company is not really affected by deprecation, but we do use Atlas Search.
So I can imagine what it’s like when you suddenly read that a service that is a basic building block of applications will simply be deleted in a year.
Our trust in MongoDB is therefore also gone. We had also considered trying Vector Search, but I will strongly advise my company against it and also against other Atlas services.
I agree that MongoDB has positioned itself too broadly with Atlas and offers too many services. This is also reflected in the services, which are only updated irregularly and too little. Atlas Search is very limited in terms of functions compared to competing products. I suspect the same applies to Vector Search, Stream Processing and other services. But simply removing a service in such a short period of time is definitely not the solution.
I completely understand your concern. What I will say is this was a very difficult decision made to help us focus more on what we’ve heard matters most to our customers: advancing our core MongoDB Atlas database. We’re prioritizing resilience, elasticity, cost-efficiency, and scalability and also expanding investments in integrated Search and Vector Search, bringing these features to MongoDB Community, and increasing our support for the growing demand in Stream Processing.
I want to reiterate Joel’s message above: we realize in some cases, our timeline may pose a significant challenge. If you feel that you need more time, please reach out to your account executive, MongoDB Support Portal, or if you are not a subscription customer, please use the chat feature when logged into MongoDB Atlas. If for whatever reason you cannot get in touch, feel free to reach out to me directly: andrew dot davidson at mongodb dot com
I want to assure you that the MongoDB team cares greatly about this situation. We recognize the frustration and concern it has caused, and we are committed to rebuilding the trust you’ve put in us that has been impacted. The decision we’ve made was not taken lightly, and we are actively working to provide alternative ecosystem solutions, update available resources, and offer support wherever possible.
Just a heads up that there are now 200+ posts in this thread and countless others who have seen this thread but don’t feel the need to chime in because it does seem fruitless that what matters most to us (your customers, not just community members) is that Device Sync not be discarded.
We are clearly not the customers you are listening to, so please stop saying this line. It is incorrect. Read the room, bro.
“what we’ve heard matters most to our customers: advancing our core MongoDB Atlas database.”
I can’t speak for anyone else but what mattered most to this customer was the device sync. We went with realm + atlas cloud db because we had to to get the device sync. We now have to look elsewhere for device sync and we’ll just pick whatever cloud option works with that. This customer in particular was going to be paying for over 100 atlas databases as part of a multi-tenanted solution built off the back of your device sync feature. You guys really don’t seem to get the value of this thing and your primacy in the space. You could have charged more instead of deprecating it.
To Mongo leadership.
This is wild, and you’ve lost all the trust teams before you have built over countless years.
Device Sync, was a great product and far ahead tech wise compared to any other real competitor (Couchbase or Firebase). A decision to fully deprecate Device Sync to support the AI bubble, that will undoubtedly burst, makes this decision even more hilarious.
If revenue was an issue, as your officials keep hinting towards, I’m 100% certain that a decision to introduce pricing to Device Sync would’ve been a far smaller stain to the image of your company, rather than fully removing this service. Without a doubt people would’ve complained, but at the end of the day they would’ve most likely pay just because of how great the product was.
I would.
I will end with, thanks for truly showing this community that it isn’t about the developers but the share holders that care about the latest buzz words in tech. As developers we will now make the prudent decision of making MongoDB our last choice.
