This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(256, 15%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EWV%3C/text%3E%3C/svg%3E)
I am not able to setup my CosmosDb account level througput as code with bicep. It is not available as stated here: https://learn.microsoft.com/en-us/azure/cosmos-db/table/manage-with-bicep
To be honest, this isn't a tip but a missing implementation.
It is impossible to create a CosmosDb account with tables without manual intervention. And you can only set the shared throughput as long no table was created yet.
Please guide me how to configure a CosmosDb Account for shared throughput without manual intervention.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(166.4, 95%, 26%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESD%3C/text%3E%3C/svg%3E)
Hello Wesley van Schaijk
Please be informed that account level throughput limit can be set by - totalThroughputLimit. You can configure using bicep, and ARM template also.
Reference document: https://learn.microsoft.com/en-us/azure/templates/microsoft.documentdb/databaseaccounts?pivots=deployment-language-bicep
If the intention is to create shared throughput at database level, https://learn.microsoft.com/en-us/azure/templates/microsoft.documentdb/databaseaccounts/sqldatabases?pivots=deployment-language-bicep
Hello Wesley van Schaijk
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
You are talking sqlDatabases, but I am talking Table API or short 'tables'.
The intention is to share throughput accross all the tables in one account instead of per table.
Hello Wesley van Schaijk
Could you please confirm, if you are planning to create new tables?
Yes, I am using https://learn.microsoft.com/en-us/azure/cosmos-db/table/
As far as I understood is it only possible -BEFORE any table is created- to configure the shared throughput on the Azure CosmosDb Account. Unfortunately this is not possible to configure as code, or I haven't found the way to achieve this.
After the shared throughput is set, I indeed want to create tables in that Azure CosmosDb Account. Those tables should share throughput within the account, as I don't want to have dedicated throughput per table.
Hello Wesley van Schaijk
Kindly please share the details requested in the private message for further investigation.
Migrating between dedicated and shared throughput in Cosmos cannot be done with Bicep or ARM templates. It can only be done using PowerShell, CLI, Azure Management SDK or REST API.
Here is Azure CLI command as an example.
Hello @Mark Brown - MSFT , am I correct if I state that manual == dedicated and autoscale == shared throughput (accross the whole account) ?
And if I am not "migrating", but want to set it up initially. How can I achieve that? Is it by creating the account, then a table, migrate that table, create next table and migrate again? Because I think that the shared throughput is set on the account level and not on individual tables.
No, manual is not dedicated nor is autoscale = shared.
Manual vs Autoscale
Manual: Fixed cost, fixed performance - like a flat rate phone plan
Autoscale: Automatically adjusts up/down based on usage - like pay-per-minute calling
Dedicated vs Shared
Dedicated: Each container gets its own guaranteed resources - like a private server Shared: Multiple containers share one pool of resources - like shared hosting
You cannot initially create a Table API account with shared throughput.
Table API has a different resource model than others API's. Other API's have account -> database -> container/collection. Table API only has account -> Table.
The Cosmos resource provider's API is polymorphic on the databaseAccount object. Because the other API's do not have throughput as a direct child of the account resource, it is not possible to create an account and provision/configure throughput on the account resource.
Customers wanted a way to support shared throughput on their Table API resources, so we implemented a workaround using the throughput migration operation using a hidden database resource that cannot be accessed to hang the throughput off of.
Before going down this route of shared throughput I would familiarize yourself with how throughput works in Cosmos. https://learn.microsoft.com/en-us/azure/cosmos-db/request-units. I would be especially cautious using shared throughput. Unlike dedicated throughput (manual/standard or autoscale), shared throughput does not have any latency or performance guarantees. In addition, if you have tables with drastically different request and storage volumes you might get poor performance. Shared throughput works best when the tables have similar request and storage profiles. Tables that have higher request/storage needs should get their own dedicated throughput.
One other note is the use of Table API. This API was created to provide a way for Azure Table Storage users a way to have scalable key/value storage with high performance. Your direction of using shared throughput is an anti-pattern to what Table API was designed for. If you are using Table API as a means of modernizing an existing application, this may be fine for a short time. Overtime however, it is recommended to migrate to using the NoSQL API which provides the same key/value functionality using partition key and id. If designing a new workload, it is recommended to use NoSQL directly. It has more features and provides performance guarantees (when using Direct Mode in our SDKS). It also is not going through a layer to emulate the legacy Azure Storage Table interface.
Thanks.
Hello Wesley van Schaijk
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Hello Wesley van Schaijk
We don't migrate data. If you are migrating Table Storage to Cosmos NoSQL or Table API to Cosmos NoSQL, you can use ADF or this tool here, https://github.com/AzureCosmosDB/data-migration-desktop-tool
An alternative too for them is If you have multiple small tables with minimal usage you can migrate those to a Table API account with shared throughput and put others with large storage and/or with high request rates into the same Table API Account with dedicated throughput. You should avoid using shared throughput for all of them. Ideally however, for best performance, features, etc. NoSQL API using .NET or Java SDK is the way to go.
Even if you go with NoSQL however, you should use the same technique with multiple containers using shared throughput and large ones with their own dedicated throughput.
Hi Wesley. This comment above is from me. I sent to Saraswathi to post here. Any further questions, please let me know. Thanks.
Hello Wesley van Schaijk
We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Else, If this answers your query, do click Accept Answer and Upvote for was this answer helpful.
Hello @Mark Brown - MSFT ,
I am trying to use the migrate command to setup shared throughput, but without success.
I want to go from:
To this:
And if we compare the Cost Management tab, I want to go from:
To:
You can ignore the number of tables in the desired state, that will be more than 1.
Can you share the error message you received when running the az cli command?
We don't get any error messages. I am just not able to set the shared throughput. The only thing that is changing is the throughput mode from manual to autoscale.
Maybe we can plan a MS Teams session so I can show you what's going on?
Hi Wesley. The best way to handle this is to open a support ticket. Our support engineers are better equipped to see your requests to our control plane from azure cli and our backend telemetry for this operation. Apologies I cannot help with this directly. But I do hope this helps.
Thanks.