The Australia Regions are available to customers with a business presence in Australia or New Zealand.
The India regions are currently available to volume licensing customers and partners with a local enrollment in India. For more information, contact your Microsoft India partner manager or account manager. The India regions will open to direct online Azure subscriptions in 2016.
Azure Government is available to US government entities to purchase physically and network isolated instance of Azure Government from a Licensed Azure Government Service Provider or Partner with no upfront financial commitment or fee. Or, you can sign up for a free Azure Government trial.
Important: The price in R$ is merely a reference; this is an int'l transaction and the final price is subject to exchange rates and the inclusion of IOF taxes and an eNF will not be issued.
DocumentDB is not available in the Brazil South region. Please select another region.
DocumentDB is not available in the West US 2 region. Please select another region.
DocumentDB is not available in the West Central US region. Please select another region.
At any scale, you can store data and provision throughput capacity. Each collection is billed hourly based on the amount of data stored (in GBs) and throughput reserved in units of 100 RUs/second.
|SSD Storage (per GB)||$0.25 per GB / month|
|Reserved RUs /second (per 100 RUs)||$0.008/hr (~$5.952/mo)|
For high-throughput and high-storage workloads you can create partitioned collections by defining a partition key at collection creation. A partitioned collection will seamlessly scale out as the quantity of stored data grows and reserved throughput increases.
DocumentDB collections can be globally distributed to help you easily build apps with planet scale which means all of your data is automatically replicated to the regions you specify. Your app continues to work with one logical endpoint, while your data is automatically served from the region closest to your users with an intuitive programming model for data consistency and 99.99 availability. Globally distributed collections are billed based on the storage consumed in each region and throughput reserved for each DocumentDB collection x the number of regions associated with a DocumentDB database account. Standard data transfer rates apply for replication data transfer between regions. As an example, say you have a database account spanning three Azure regions and two collections provisioned with 1M RUs and 2M RUs respectively. The total RUs provisioned for the first collection will be 3M RUs (1M RUs x 3 regions) and the second one will be 6M RUs (2M RUs x 3 regions).
With DocumentDB you can write a sustained volume of data and it will be synchronously indexed to serve consistent SQL queries using a write-optimized, latch-free database engine designed for solid-state drives (SSDs) and low latency access. Read and write requests are always served from your local region while data is distributed globally. You can further optimize performance by customizing automatic index behavior.
DocumentDB also offers collections with pre-defined 10GB storage and throughput quantities- S1 (250 RU/s billed at $0.0336/hr), S2 (1000 RU/s billed at $0.0672/hr), or S3 (2500 RU/s billed at $0.1344/hr). If you want to reconfigure throughput for these collections, see Changing performance levels using the Azure Portal. If you want to take advantage of partitioned collections, you need to convert your previously created S1, S2, or S3 collections to use the limitless throughput and storage scale described above, as described in Partitioning and scaling in Azure DocumentDB.
A Request Unit (RU) is the measure of throughput in DocumentDB. 1 RU corresponds to the throughput of the GET of a 1KB document. Every operation in DocumentDB, including reads, writes, SQL queries, and stored procedure executions has a deterministic Request Unit value based on the throughput required to complete the operation. Instead of thinking about CPU, IO and memory and how they each impact your application throughput, you can think in terms of a single Request Unit measure.
For more information about Request Units and for help determining your collection needs, please go here
You are billed hourly for each collection created within a DocumentDB account. Each collection is billed a flat, predictable hourly rate based on the number of Request Units that have been provisioned during that hourly period.
Storage capacity is billed in units of the maximum hourly amount of data stored, in GB, over a monthly period. For example, if you utilized 100 GB of storage for half of the month and 50GB for the second half of the month, you would be billed for an equivalent of 75 GB of storage during that month.
You are billed the flat rate for each hour the collection exists, regardless of usage or if the collection is active for less than an hour. For example, if you create a collection and delete it 5 minutes later, your bill will reflect a charge for 1 unit hour.
If you define your own performance for a collection and you upgrade at 9:30AM from 400 RUs to 1,000 RUs and downgrade at 10:45AM back to 400 RUs, you will be charged for two hours of 1,000 RUs.
If you select a pre-defined collection performance level and you upgrade at 9:30AM from an S1 collection to an S3 collections and downgrade at 10:45AM back to S1, you will be charged for two hours of S3.
You can scale up or scale down the number of Request Units for each collection within your DocumentDB account by using the Azure Portal, one of the supported SDKs or the REST API.
Yes, you can have a mix of collections. However, for new applications, it is encouraged to create collections with user-defined performance as they can support large storage sizes and provisioned throughput, as well as a flexible and granular billing model.
Yes, this is possible and encouraged.
To move a collection of S1, S2, or S3 performance tier to the user-defined performance tier with the same storage size, see Changing performance levels using the Azure Portal.
To move an existing single collection to a partitioned collection, see Partitioning and Scaling in Azure DocumentDB.