Docs Menu
Docs Home
/ /
Atlas App Services
/ /

Device Sync Production Checklist

On this page

  • Atlas Cluster Configuration
  • App Services Configuration
  • Client Application Code
  • Data Model and Schema
  • Performance Best Practices

We recommend following these best practices to ensure optimal performance and a smooth user experience.

For related information about service limitations, refer to Service Limitations.

Use a dedicated Atlas cluster

Production Apps should use, at minimum, an M10 dedicated cluster. Depending on your use case, you may need to upgrade to a higher tier for optimal performance.

If you use a shared cluster, like an M0, M2, or M5, you may experience performance issues due to limited resources and contention with other users. If you upgrade from a shared tier to a dedicated tier after you go to production, you will need to terminate Device Sync and reset or re-install all client applications.

Atlas oplog
Device Sync requires access to a time-based oplog for your synced cluster. All new Atlas clusters provide this by default. For best results, keep 48 hours of oplog for a cluster using Device Sync.
MongoDB version
Use the latest version of MongoDB, if possible. Some Device Sync optimizations use new MongoDB version features and enhancements.
NVMe minimum MongoDB version
If your cluster runs on hardware that uses NVMe storage, it must use MongoDB version 6.0 or later for Device Sync production applications.
Disable or manage built-in schema validation

A schema in App Services is not the same as MongoDB's built-in schema validation. Device Sync may interact with your cluster in a way that is incompatible with a built-in schema.

If you use schema validation on your cluster, you should either disable it in favor of App Services schemas or manage the two schema validation layers so that they're compatible. For more information, see App Services Schema vs Built-In Schema Validation.

Deployment model and geographic regions
Use a local deployment model when building a Device Sync application. Configure your App and MongoDB data source to run within the same geographic region and cloud provider.
Define a client maximum offline time
The App Services backend uses a history of changes to underlying data to synchronize clients. Configure a client maximum offline time to control the number of days of history stored by your App. Clients that have not synchronized in more than that number of days must perform a client reset the next time they connect to the backend.
Define a client reset handler
To recover from a serious error conditions where the client and server histories diverge, you should define a client reset handler when you open each synced realm with an SDK.
Avoid breaking changes
Once you've enabled Sync, there are limitations on how you can modify your data model. Specifically, Sync does not support breaking changes to your object types such as changing a given property's type. If you want to make a breaking change you need to terminate and re-enable Sync with the updated data models.
App Services schema data consistency
If you create or modify Device Sync documents using another tool, such as the mongosh shell or MongoDB Compass, be sure the documents validate against the App Services Schema for the collection. For more information, see Unsynced Documents.
Production load testing
Measure performance and identify issues in a scaled-up production deployment with Sync Production Load Testing.
Write transaction size
When writing large amounts of data, consider using multiple small write transactions instead of a single larger transaction. Depending on your Atlas cluster version and configuration, write transactions greater than 16MB may be rejected by MongoDB and cause the sync operation to fail.
← Go to Production with Atlas Device Sync