Types of quota
The Earth Engine platform has a number of quota limits in place to ensure that resources are distributed fairly across users. Since there are many different types of resources available in Earth Engine (computation, storage, etc.), there are many different types of quota limits.
The primary distinction between different quota types is whether they're adjustable. For some types of quota, we're able to change the limits on a per-user or per-project basis, while other types are system-wide limits which can't be changed.
Adjustable quota limits
The following limits may be adjusted on a per-project basis. See the help page for how to request additional quota.
| Quota type | Default value (per project) |
|---|---|
| Max concurrent requests (standard endpoint) | 40 concurrent requests |
| Max concurrent requests (high-volume endpoint) | 40 concurrent requests |
| Max rate of requests (per project) | 100 requests/s (6000 requests/min) |
| Max rate of requests (per account) | 100 requests/s (6000 requests/min) |
| Average concurrent batch tasks | 2 tasks (on average) |
| Max asset storage space | 250 GB |
| Max number of assets | 10,000 |
Concurrent interactive requests
Each project can make interactive requests in parallel, up to a quota limit. If the limit is exceeded, Earth Engine will return "HTTP 429: Too Many Requests" errors. Generally, these errors are handled by the Earth Engine client library, which wraps requests in exponential backoff, retrying the query until it succeeds. The Earth Engine client library will retry the request up to five times.
To help avoid receiving these 429 errors, you may want to enable caching for your application, for example using memcache, to avoid redundant queries when possible. If using an older version of the Earth Engine client library that does not retry queries automatically, or if a query is still not completed after five retries, you may need to implement exponential backoff around requests.
Rate of requests (QPS)
In addition to the concurrency limits, Earth Engine limits the rate of interactive requests at the project and user level. These settings can be adjusted in the Cloud Console
Concurrent batch tasks
Batch tasks are limited to a small amount of parallelism, since they use more resources than interactive requests.
When using Earth Engine noncommercially, the maximum number of batch tasks that you're able to run concurrently is set to the default unless you've been granted a quota uplift.
When using Earth Engine commercially, the maximum number of batch tasks that you're able to run concurrently is determined by the pricing plan, though it may be further lowered by setting the per-project batch task concurrency limit. By default, the batch task concurrency limit on a project is set to the maximum allowed by the payment plan configured on the project's billing account. To view or update this limit on a project, see the documentation for the command line tool.
Asset storage quota
Each Earth Engine asset has a corresponding data storage size measured in bytes. Assets can be owned by Cloud Projects or by individuals (legacy assets), and each asset counts against its owner's Earth Engine limit on overall storage and asset count.
Fixed quota limits
These types of quota limits are set at the platform level, so they can't be adjusted on a per-user or per-project basis. They're unlikely to change significantly over time.
Computation time
Different types of requests have different maximum durations, which are detailed in detail in the Processing Environments documentation.
For help fixing timeout errors, see the debugging guide.
Per-request memory footprint
When a request fails with "User memory limit exceeded", this means that Earth Engine was unable to compute the answer within the allowed memory footprint. The EE computation platform has a finite amount of RAM available, and, to ensure that the system remains stable, each request can only use a certain amount. The maximum amount of memory available depends on the type of request (e.g., more for a batch task than a map tile), but these are system-wide limits.
For help fixing memory errors, see the debugging guide.
Aggregations
When processing Earth Engine requests, we separate off certain types of sub-computations which we know are computationally intensive. These sub-computations are called "aggregations," and they're handled specially in the EE system. The results of aggregations are cached to avoid recomputation.
Concurrent aggregations
To avoid uncontrolled computational fanout, we limit the number of aggregations that an individual user can run simultaneously, and this is unchangeable. When a request fails with "Too many concurrent aggregations", it means that the requester had too many aggregations running at the same time.
For help fixing concurrent aggregation errors, see the debugging guide.
Large aggregation results
When a request fails with "Computed value too large", it means that the aggregation returned a result which is too large to fit in our cache. The size limit on computed results is 100 MiB, and this is a system-wide limit.
Table import limits
Table upload limits are explained in the the guide to importing table data.
Request payload size
A single query to Earth Engine is limited to 10MB in size. This limit is usually only exceeded when some large piece of additional data gets included directly in the query, like a shapefile or GeoJSON structure that's been inlined into the query. These objects should instead be uploaded and turned into a FeatureCollection asset, and referenced by the asset ID.
Task queue length
Tasks that are waiting to be scheduled (in the READY state) form the "task
queue." Each project's queue supports a maximum of 3,000 tasks. This means that
it's not possible to have more than 3,000 tasks in the READY state.