Intro
Mike: Thank you so much for joining us here today.
Steve: Thanks, Mike, it's my pleasure.
Mike: From what we can tell, you're working on a few apps — Paper, a note-taking app, BeFit for exercise logging, and a few others. Could you please share a bit more about your background and the different apps you're currently working on?
Steve: Yeah, so to talk about myself a little bit, I’m Steve. I live in France, and I spend most of my time writing and reading code. I've been doing this for a bit more than four years now, and I’m working full-time as a mobile developer.
I love to experiment and learn new things, which is why I spend a lot of time on pet projects. I use these pet projects to fill needs I have on a daily basis. For instance, I needed a simple note-taking app, so I built Paper, which is my biggest app today with a bit more than 1,000 active users.
I also needed to track my progress at the gym, so I built BeFit. Additionally, I’ve created apps for specific needs for myself or my relatives.
Reacting to MongoDB's Deprecation Announcement
Mike: We recently noticed that you tweeted about migrating an app from MongoDB Atlas Device Sync to PowerSync with Supabase as your backend database. Many developers are in the same position you were, learning about MongoDB's decision to deprecate Atlas Device Sync and wondering about the best way forward. Could you take us through how you reacted to that news and some of the steps you took to migrate your apps?
Steve: I was already considering migrating off Realm for a few reasons. I had tried the Supabase + PowerSync combo on a project and loved it.
I found Realm extremely painful to work with — it was so rigid. Even small schema changes could result in runtime errors, which was frustrating. You had to rely on code generation, which felt like overkill. The process felt fragile, like walking on eggshells.
Beyond that, Realm felt overly complex. You had to manage sync rules, schema versions, and migrations — either upgrading schema versions or manually writing migration code when you made model changes.
Realm's authentication system was another hurdle — it wasn’t compatible with web apps. My users wanted a web app, but I couldn’t deliver one.
Finally, switching from local to synchronized mode in Realm required creating a new database file and manually copying data from the offline database. This was error-prone and didn’t feel right.
When MongoDB announced the deprecation, it gave me a solid reason to start migrating.
Learning About PowerSync
Mike: How did you first learn about PowerSync, and what made you want to evaluate it further?
Steve: I think I saw a post about PowerSync on Twitter from Sebastian Röhl, the creator of HabitKit.
I checked it out and fell in love with the philosophy. Most of my apps don’t necessarily need an internet connection to work, so PowerSync’s approach — using a SQL database while synchronizing changes across users’ devices — spoke to me.
The Migration Process
Mike: What were the steps you took to move from MongoDB Atlas Device Sync and Realm to Supabase and PowerSync?
Steve: For context, I was using Firebase for user authentication in the legacy system. Migrating involved a few key components:
- Firebase to Supabase Migration: This was straightforward, thanks to Supabase’s excellent migration tools.
- User Data Migration: This was more complex because we had:some text
- Offline-only users without accounts (no cloud sync enabled).
- Users with accounts, some with data spanning multiple devices in different states.
To use Supabase for authenticating the PowerSync client against the server, user IDs needed to come from Supabase, not Firebase. We had to handle user ID changes during migration while maintaining data ownership.
We implemented two key solutions:
- Client-Side Migration Flow: This copied data from the Realm database to SQLite, ensuring offline users could still access their data.
- Remote Migration Tool: This transferred data from MongoDB collections to Supabase tables. PowerSync then synchronized this data to users' local databases.
We relied on PowerSync’s built-in conflict management for this process, which worked perfectly. We migrated 20,000 notes without any issues.
Finally, we implemented a forced upgrade mechanism in the mobile app to prevent users from saving data in the legacy system.
Adjusting to SQLite and Sync Rules
Mike: How did you find the transition from working with Realm to SQLite and PowerSync’s Sync Rules?
Steve: I didn’t face any major issues. I was already familiar with Realm’s sync system (despite its flaws), and PowerSync has excellent documentation.
The YAML syntax for Sync Rules was intuitive, and PowerSync’s examples made it easy to get things working.
Advice for Developers Reacting to MongoDB's Decision
Mike: What advice would you give to developers wondering how to respond to the Atlas Device Sync deprecation?
Steve: First, consider migrating to a new solution — MongoDB is shutting it down.
For me, PowerSync is ideal for several reasons:
- Setup took only 1–2 hours the first time.
- It’s non-intrusive, letting you retain control over how write operations are handled.
- It supports MongoDB, MySQL, and PostgreSQL, so larger apps can use PowerSync as a sync engine without switching infrastructure.
- Maintenance has been minimal. Everything just works, and I’ve only had to focus on adding new features.
Closing
Mike: Thank you for joining us today and sharing your journey. We wish you all the best!
Steve: Thanks, it was my pleasure!
Video
Watch the video of this conversation:
