Docs Home → Atlas App Services
Device Sync Production Checklist
On this page
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.
Atlas Cluster Configuration
- Use a dedicated Atlas cluster
Production Apps should use, at minimum, an
M10dedicated 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, orM5, 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.
App Services Configuration
- 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.
Client Application Code
- 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.
Data Model and Schema
- 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.
Performance Best Practices
- 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.