On this page
Atlas App Services has several guidelines to keep in mind when architecting how your tools and clients interact with MongoDB through App Services. Keep this guidance in mind when deciding how to structure queries, selecting which CRUD and aggregation operations to use, and determining how to handle concurrent workloads.
For security reasons, only a subset of aggregation pipeline stages are supported in user functions.
For a list of pipeline stages that are available and their allowed function context, see Aggregation.
When data is bulk/batch loaded into MongoDB Atlas, you may see a delay in data appearing on devices while Atlas App Services processes changes.
You can link a Data Lake to your app as a MongoDB data source. However, there are some caveats to keep in mind when working with a Data Lake:
- Data Lakes do not support write operations.
- You can only access a Data Lake from a system function.
- You cannot connect to a Data Lake via the wire protocol.
- You cannot define roles and permissions for a Data Lake.
- You cannot set a read preference for a linked Data Lake.
- You cannot create a database trigger on a Data Lake.
- You cannot use a Data Lake as your app's synced cluster.
You can link a serverless instance to your app as a MongoDB data source. However, serverless instances do not currently support change streams, so the following features are limited:
Atlas Device Sync does not currently support sharded MongoDB Atlas clusters. However, you can add a sharded cluster as a data source and access it from a function.
App Services limits the total number of change streams open against a given
cluster across all Apps based on the cluster's size. It also limits the
number of client applications that can concurrently listen for changes using
watch() and Sync. The
following table lists the limitations for each cluster size:
Maximum Number of Change Streams
Maximum Number of Concurrent Listening Clients
Free Tier (
Shared Clusters (
Small, Dedicated Clusters (
Standard Clusters (
Standard Clusters (
High-Power Clusters (
100000 (Contact Support for Additional Usage)
To minimize the number of concurrent listening clients and open change streams:
- Start Watch and Sync operations only when necessary. Close any open Watch and Sync streams immediately when they're no longer necessary.
- Avoid data models that require you to Watch or Sync an unbounded number of collections.
App Services does not support any database commands in the Client SDKs or Functions. You can, however, call a limited subset of database commands when when connected to a MongoDB cluster over the wire protocol. For a list of supported commands, see Database Commands.
You can access most of the CRUD and Aggregation functionality of MongoDB version 3.6 with the MongoDB service; however, Atlas App Services does not support all operations and features available in standard tools and clients. For a list of specific MongoDB operations that are available when you connect to MongoDB through App Services, see the CRUD & Aggregation API reference.
Atlas Device Sync requires MongoDB Atlas clusters to run MongoDB 4.4.0 or greater.
App Services supports all query options in system functions. App Services does not support certain options for CRUD operations run from user functions. For a list of specific options that are available when you connect to MongoDB through App Services, see Query Options.
MongoDB queries executed through App Services can return a maximum of 50,000 documents. If you need to return more documents, consider paginating your query.
Atlas App Services limits request traffic to 5,000 concurrent requests. Any requests made beyond this limit return an HTTP response status code of 429 - Too Many Requests. You can request a higher limit by filing a support ticket.
App Services enforces a 25MB maximum file size constraint on static hosting.
- Atlas App Services supports up to 30 users concurrently writing data to an underlying MongoDB document. With more than 30 concurrent writers, you may see delays in syncing or conflict resolution.
- Frontend clients reading from a global realm can scale past tens of thousands of concurrent users.
When you intend to have many concurrent writers, have each writer work on a separate document.