Global Config Limits and pricing
A Global Config is a global data store that enables experimentation with feature flags, A/B testing, critical redirects, and IP blocking. It enables you to read data in the region closest to the user without querying an external database or hitting upstream servers.
Keep the number of stores to a minimum. Fewer large stores improve your overall latency.
The following table outlines the price for each resource according to the plan you are on:
| Resource | Hobby Included | On-demand Rates |
|---|---|---|
| Global Config Reads | First 100,000 | $3.00/1,000,000 Reads |
| Global Config Writes | First 100 | $1.00/100 Writes |
The following table outlines the limits for each resource according to the plan you are on:
| Hobby | Pro | Enterprise | |
|---|---|---|---|
| Maximum store size | 1 MB | 1 MB | 1 MB |
| Maximum number of stores (total) | 1 | Unlimited | Unlimited |
| Maximum number of stores connected to a project | 1 | 3 | 3 |
| Maximum item key name length | 256 characters | 256 characters | 256 characters |
| Write propagation | Up to 10 seconds globally | Up to 10 seconds globally | Up to 10 seconds globally |
| Backup retention | 7 days | 90 days | 365 days |
The table below shows the metrics for the Global Config section of the Usage dashboard.
To view information on managing each resource, select the resource link in the Metric column. To jump straight to guidance on optimization, select the corresponding resource link in the Optimize column.
Metric | Description | Priced | Optimize |
|---|---|---|---|
| Reads | The number of times your Global Config has been read | Yes | Learn More |
| Writes | The number of times your Global Config has been updated | Yes | Learn More |
See the manage and optimize Global Config usage section for more information on how to optimize your usage.
Reads indicate how often your project has requested access to Global Config to retrieve data through the SDK or the REST API. Vercel counts it as one read, regardless of whether you retrieve one or all items.
Writes represent how often you updated your Global Config through the SDK or the REST API.
The maximum store size represents the total size limit of each Global Config store, including all keys and values of the document.
The maximum number of stores represents the total number of Global Config stores that you can create for your account or team.
The maximum number of stores connected to a project represents the total number of Global Config stores that you can connect to a single project. Exceeding this amount will result in an error.
Each key name in your Global Config can be up to 256 characters long. The key name must adhere to the regex pattern ^[\w-]+$, which is equivalent to /^[A-Za-z0-9_-]+$/, and allows A-Z, a-z, 0-9, _, and -.
When updating an item in your Global Config, it may take up to 10 seconds for the update to be globally propagated. You should avoid using Global Configs for frequently updated data or data that needs to be accessed immediately after updating.
Backups are automatically saved when you make any changes, allowing you to restore to a previous version. See the table above to learn about how long backups are saved for.
To learn more about backups, see Global Config backups
The Reads chart shows the number of times your Global Config has been read. You can filter the data by Count or Projects.
- Open Project in the sidebar to identify which project has the most Global Config reads
- Review how you access the stores through both the REST API and the SDK. They both count toward your reads
- Where possible, use
getAll()instead of separateget(key)calls with the SDK, ensuring they count as a single read.
The Writes chart shows the number of times your Global Configs were updated. You can filter the data by Count or Global Configs.
- Open Global Configs in the sidebar to identify which Global Config has the most Global Config writes
- Review your points of updating the stores through the REST API as they count towards your writes
If reading from your Global Config seems slower than expected, ensure that the following are true:
- You've set the connection string as an environment variable
- You are using the SDK to read from your Global Config
- You see the Global Config icon on the row for the connected environment variable on the Environment Variables page of your project settings
- You are testing on your Vercel deployment, as the optimizations happen only when you deploy to Vercel


Error: Tried to attach 4 Global Configs. Only 3 can be attached to one Deployment at a time.
You are limited to a maximum of 3 Global Config stores connected to any single project.
If you get this error, review your storage by visiting the Vercel Dashboard, selecting your project, and selecting the Storage section in the sidebar. You can use the search filter to see only your Global Configs. You will have to disconnect one of the stores and redeploy your project.
To learn how to prevent this error, see best practices.
Updates to items in your Global Config will be rejected if the resulting size of your Global Config would exceed your account plan's limits. When this happens, all members of your team will receive a notification from Vercel, whether the error originated in the dashboard, an API request, or an Integration. The Global Config editor in your dashboard can detect many cases where the final size would exceed the limit and warn you upfront without triggering the notification.
To resolve this issue, you can:
- Delete unused entries from your Global Config to free up space
- Split data across multiple stores
- Where possible, having fewer large stores is better than having multiple small stores, as having fewer Global Config stores requested more often leads to lower overall latency.
If you are developing locally or self-hosting, your Global Config is loaded through the public internet network. In this case, you may wonder if it's safe to have the token as a parameter in the connection string.
- It is safe to have the token as a parameter in the connection string, because the SDK parses the passed string, then sends the token through an
Authorizationheader instead
Was this helpful?