Frequently asked questions about Azure Cosmos DB

Azure Cosmos DB is well suited for web, mobile, gaming, and IoT use cases. In these use cases; automatic scale, predictable performance, fast order of millisecond response times, and the ability to query over schema-free data is important. Azure Cosmos DB lends itself to rapid development and supporting the continuous iteration of application data models. Applications that manage user-generated content and data often map to common use cases for Azure Cosmos DB.

A request unit (RU) is the measure of throughput in Azure Cosmos DB. A single request unit throughput corresponds to the throughput of the GET HTTP action for a 1-kilobite document. Every operation in Azure Cosmos DB; including reads, writes, queries, and stored procedure executions; has a deterministic request unit value based on the throughput required to complete the operation. Instead of being forced to consider CPU, IO, and memory in relation to your application throughput, you can think in terms of request units.

You can configure each Azure Cosmos DB container with provisioned throughput in terms of request units per second (RU/s). You can benchmark individual requests to measure in request units, and create a container to handle the sum of request units across all requests for that container in a second. You can also scale up or scale down your container's throughput as the needs of your application evolve. For more information on how to measure request units, see the throughput calculator.

Key/value (table), columnar, document, and graph data models are all natively supported because of the ARS (atoms, records, and sequences) design that Azure Cosmos DB is built on. Atoms, records, and sequences can be easily mapped and projected to various data models. The APIs for a subset of models are available using the ARS design (MongoDB RU, NoSQL, Table, Apache Cassandra, and Apache Gremlin). Azure Cosmos DB also supports other APIs such as MongoDB vCore, Cassandra MI, or PostgreSQL.

A container is a group of items. Containers can span one or more partitions and can scale to handle practically unlimited volumes of storage or throughput.

A container is a billable entity, where the throughput and used storage determines the cost. Each container is billed hourly, based on the provisioned throughput and used storage space. For more information, see Azure Cosmos DB pricing.

Azure Cosmos DB is Microsoft's globally distributed, multi-model database service. Multi-model refers to Azure Cosmos DB's support for multiple APIs and data models. In this paradigm, different APIs use different data formats for storage and wire protocol. For example; NoSQL uses JSON, MongoDB uses binary-encoded JSON (BSON), Table uses Entity Data Model (EDM), Cassandra uses Cassandra Query Language (CQL), Gremlin uses JSON format. As a result, we recommend using the same API for all access to the data in a given account.

Yes. Azure Cosmos DB APIs allow direct integration. For example, the Azure Cosmos DB REST APIs can be integrated with Azure API Management for CRUD operations, eliminating the need for intermediate services like Azure Functions.

Yes, Azure Cosmos DB is HIPAA-compliant. HIPAA establishes requirements for the use, disclosure, and safeguarding of individually identifiable health information. For more information, see the Microsoft Trust Center.

There's no limit to the total amount of data that a container can store in Azure Cosmos DB.

There's no limit to the total amount of throughput that a container can support in Azure Cosmos DB. The key idea is to distribute your workload roughly even among a sufficiently large number of partition keys.

Yes both modes are always fully encrypted.

The number of provisioned containers, number of hours containers were online, and the provisioned throughput for each container determines Azure Cosmos DB usage charges. For more pricing details, refer to Azure Cosmos DB pricing.

To ask a technical question, you can post to one of these two question and answer forums:

• Microsoft Question & Answers (Q&A)
• Stack Overflow. Stack Overflow is best for programming questions. Provide as many details as possible, making the question clear and answerable.

To fix an issue with your account, file a support request in the Azure portal.

The general guideline to migrate a Cosmos DB account to a different resource group or subscription is described in the moving Azure resources to a new resource group or subscription article.

After you successfully move the Azure Cosmos DB account per the general guideline, any identities (System-Assigned or User-Assigned) associated with the account must be reassigned. This reassignment is required in order to ensure that these identities continue to have the necessary permissions to access the Key Vault key.

If your Cosmos DB account has Customer Managed Keys enabled, you can only migrate the account if it's a cross-tenant customer-managed key account. For more information, see the guide on configuring cross-tenant customer-managed keys for your Azure Cosmos DB account with Azure Key Vault.

When migrating from periodic mode to continuous mode, you can't run any control plane operations that performs account level updates or deletes. For example, operations such as adding or removing regions, account failover, updating backup policy etc. can't be run while the migration is in progress. The time for migration depends on the size of data and the number of regions in your account. Restore action on the migrated accounts only succeeds from the time when migration successfully completes.

You can restore your account after the migration completes. If the migration completes at 1:00 PM PST, you can do point in time restore starting from 1:00 PM PST.

Yes.

API for NoSQL, API for Table, Gremlin API, and API for MongoDB accounts that use shared, provisioned, or autoscale provisioned throughput support migration to continuous backup.

Accounts with Azure Synapse Link enabled, or that had Azure Synapse Link disabled for one or more collections, can't migrate to continuous backup.

Migration takes a varying amount of time that largely depends on the size of data and the number of regions in your account. You can get the migration status using Azure CLI or PowerShell commands. For large accounts with tens of terabytes of data, the migration can take up to few days to complete.

Yes, this migration takes time that largely depends on need to wait for all old tentative writes to get drained during continuous backup migration. You can get the migration status using Azure CLI or PowerShell commands. For large accounts with tens of terabytes of data, the migration can take up to few days to complete.

No, the migration operation takes place in the background. So, client requests aren't affected. However, we need to perform some backend operations during the migration, and it could take extra time if the account is under heavy load.

Once the migration process is started, the account is enabled in continuous mode. If the migration fails, you must initiate migration again until it succeeds.

Assume that you started migration at t1 and finished at t5, you can't use a restore timestamp between t1 and t5. Also assume that your account is now in continuous mode. To restore to a time after t5, perform the restore using Azure portal, CLI, or PowerShell like normally with a continuous account. This self-service restore request can only be done after the migration is complete. To restore to a time before t1, you can open a support ticket like you normally would with a periodic backup account. After the migration, you have up to 30 days to perform the periodic restore. During these 30 days, you can restore based on the backup retention/interval of your account before the migration. For example, if the backup was configured to retain 24 copies at 1 hour intervals, then you can restore anytime between (t1 – 24 hours) and t1.

Operations such as add/remove region, failover, changing backup policy, and any throughput changes resulting in data movement are blocked during migration.

Failed migration doesn't block any control plane operations. If migration fails, retry until it succeeds before performing other control plane operations.

It isn't possible to cancel the migration because migrations aren't a reversible operation. Via support call team can cancel temporarily and let the offline operations continue. But one can't move back to periodic backup state.

There isn't a tool to estimate time. Our testing and scale runs indicate that an account with 1 TB of data takes roughly 90 minutes. For multi-region accounts, calculate the total data size as Number_of_regions * Data_in_single_region.

Test the continuous backup mode feature to verify it works as expected before migrating production accounts. Migration is a one-way operation and can't be reversed.

Yes, you can sign up for a time-limited account at no charge, with no commitment. To sign up, visit Try Azure Cosmos DB for free.

If you're new to Azure, you can sign up for an Azure free account, which gives you 30 days and a credit to try all the Azure services. If you have a Visual Studio subscription, you're also eligible for free Azure credits to use on any Azure service.

You can also use the Azure Cosmos DB Emulator to develop and test your application locally for free, without creating an Azure subscription. When you're satisfied with how your application is working in the Azure Cosmos DB Emulator, you can switch to using an Azure Cosmos DB account in the cloud.

You can access a time-limited Azure Cosmos DB experience without a subscription, free of charge, and commitments. To sign up for a Try Azure Cosmos DB subscription, go to Try Azure Cosmos DB for free and use any personal Microsoft account (MSA).

This subscription is distinct from the Azure Free Trial, and can be used along with an Azure Free Trial or an Azure paid subscription.

Try Azure Cosmos DB subscriptions appear in the Azure portal with other subscriptions associated with your user ID.

The following conditions apply to Try Azure Cosmos DB subscriptions:

• Account access can be granted to personal Microsoft accounts (MSA). Avoid using Microsoft Entra accounts or accounts belonging to corporate Microsoft Entra tenants, they might have limitations in place that could block access granting.
• One throughput provisioned container per subscription for API for NoSQL, Gremlin, and Table accounts.
• Up to three throughput provisioned collections per subscription for MongoDB accounts.
• One throughput provisioned database per subscription. Throughput provisioned databases can contain any number of containers inside.
• 10-GB storage capacity.
• Global replication is available in the following Azure regions: Central US, North Europe, and Southeast Asia
• Maximum throughput of 5 K RU/s when provisioned at the container level.
• Maximum throughput of 20 K RU/s when provisioned at the database level.
• Subscriptions expire after 30 days, and can be extended to a maximum of 31 days total. After expiration, the information contained is deleted.
• Azure support tickets can't be created for Try Azure Cosmos DB accounts; however, support is provided for subscribers with existing support plans.

Azure Cosmos DB is available in the Azure portal. First, sign up for an Azure subscription. After you sign up, add an Azure Cosmos DB account to your Azure subscription.

Use Microsoft Entra ID to authenticate to Azure Cosmos DB for all APIs that support this method of authentication. For APIs that don't support Microsoft Entra ID authentication, use the keys with caution. Ensure that keys for production accounts are stored securely, such as in Azure Key Vault.

For information about regional availability for Azure Cosmos DB, see Azure products available by region. You can account your database to one or more of these regions.

The software development kits (SDKs) for Azure Cosmos DB allow configuration of the regions they use for connections. In most SDKs, the `PreferredLocations`` value is set to any of the Azure regions in which Azure Cosmos DB is available.

Azure Cosmos DB is present across all Azure regions, as specified on the Azure regions page. Because it's a core Azure service, every new datacenter has an Azure Cosmos DB presence.

When you set a region, remember that Azure Cosmos DB respects sovereign and government clouds. For example, you can't replicate data out of a sovereign region. Similarly, you can't enable replication into other sovereign locations from an outside account.

Container and database-level throughput provisioning are separate offerings and switching between either of these offerings require migrating data from source to destination. You need to create a new database or container and then migrate data using bulk executor library or Azure Data Factory.

Yes, Azure Cosmos DB supports time series analysis. You can use the change feed to build aggregated views over time series data. You can extend this approach by using Apache Spark streaming or another stream data processor.

For information about service quotas and throughput limits, see service quotas and throughout limits.

Related content

• Frequently asked questions about Azure Cosmos DB for NoSQL
• Frequently asked questions about Azure Cosmos DB for MongoDB
• Frequently asked questions about Azure Cosmos DB for Apache Gremlin
• Frequently asked questions about Azure Cosmos DB for Apache Cassandra
• Frequently asked questions about Azure Cosmos DB for Table