Choosing Between Realm Local-Only and Atlas Device Sync for Mobile Apps

Decide: Local-Only Realm or Atlas Device Sync?

When you need to store data on a mobile device, Realm can work as a simple embedded database or as a synchronized edge cache that pushes changes to MongoDB Atlas. The decision hinges on whether your data must leave the device.

Takeaway: Choose local-only when the app is a single‑user tool with no backup requirement; choose Atlas Device Sync when you need real‑time multi‑device access or a cloud dashboard.

Comparison Table

Aspect	Local‑Only Realm	Atlas Device Sync
Infrastructure	Embedded on‑device only	Local Realm + MongoDB Atlas cluster
Network dependency	None	Required for cloud updates
Authentication	None	Mandatory (JWT, email/password, etc.)
Conflict resolution	Not applicable (single writer)	Automatic last‑write‑wins operational transform
Schema migration flexibility	Standard version‑based blocks	More restrictive; destructive changes need compatibility checks

Trade‑off Details

Local‑Only Constraints

Local‑only mode gives the lowest possible latency because there is no background sync engine. Data stays on the device, so loss of the device or clearing app data means permanent loss unless you implement your own backup.

Atlas Device Sync Constraints

Sync adds a synchronization layer that mirrors a subset of cloud data defined by a Partition Value (for partition‑based sync) or a Flexible Sync query. This introduces two main overheads:

• Permission logic: you must write server‑side rules that decide which users can read or write each document.
• Storage pressure: overly broad sync queries can download gigabytes of data, exhausting local storage and memory.

Implementation: Configuration Differences

The technical difference appears when you build the Realm.Configuration object.

Scenario A – Local‑Only

Run this code on the main thread or a background worker. No special permissions beyond standard file‑system access are needed.

// Example: local‑only configuration (Realm SDK 10.x+)
const config = new Realm.Configuration({
  schema: [UserSchema, TaskSchema],
  schemaVersion: 1,
});

const realm = await Realm.open(config);

Verification: Create an object, close the app, restart it without network, and query the object. If the data is still present, the local store works.

Scenario B – Atlas Device Sync

Sync requires an authenticated user. The sync property replaces the plain configuration and points the local Realm to a specific App ID.

// Example: sync configuration (assumes user already logged in)
const user = await app.logIn(Realm.Credentials.emailPassword(email, password));

const config = new Realm.Configuration({
  sync: {
    user: user,
    partitionValue: 'user-partition-123', // partition‑based sync
  },
  schema: [UserSchema, TaskSchema],
});

const realm = await Realm.open(config);

Verification: Perform a write locally, then open the MongoDB Atlas UI in a browser and confirm the document appears in the linked collection in near‑real time.

Limitations and Practical Checks

• Schema rigidity in Sync: Renaming or deleting a field requires a compatible migration strategy; otherwise the sync session may halt.
• Cold‑start latency: The first open of a synced Realm may take extra time while the sync engine negotiates the initial state.

To check that you are not accidentally pulling too much data, monitor the local Realm file size after a sync cycle; a sudden increase indicates a overly permissive query.

Rollback from Sync to Local‑Only

If you decide to stop using Sync and revert to a pure local Realm, you must delete the synced Realm file first because its internal format is incompatible with a standard local Realm.

// Delete the synced realm before opening a local‑only one
await Realm.deleteRealm(syncConfig);
const localConfig = new Realm.Configuration({ schema: [UserSchema, TaskSchema] });
const localRealm = await Realm.open(localConfig);

After deletion, you can open a local‑only Realm as shown in Scenario A.