Azure Cosmos DB serverless now in preview

Thomas

This blog post was co-authored by Nikisha Reyes-Grange, Senior Product Marketing Manager, Azure Marketing.

UPDATE: Serverless preview support for Azure Cosmos DB APIs for MongoDB, Cassandra, Gremlin, and Table began November 11, 2020. 

We are beyond excited to announce that Azure Cosmos DB serverless is now available in preview on the Core (SQL) API, with support for the APIs for MongoDB, Gremlin (graph), Table, and Cassandra coming soon. This new consumption-based model lets you use your containers cost-effectively, without having to provision any throughput.

What is serverless on Azure Cosmos DB?

Announced at the Build conference this past May, serverless radically changes the way you use and pay for your Azure Cosmos DB resources.

Until now, your only option for running a workload on Azure Cosmos DB has been to provision throughput. This throughput, expressed in Request Units per second (RU/s), is dedicated to your usage and available for your database operations to consume. This model comes with low-latency and high-availability SLAs, making it a great fit for high-traffic applications needing guaranteed performance – but not as well-suited to light traffic scenarios.

Serverless is a cost-effective option for databases with sporadic traffic patterns and modest bursts. When your resources sit idle most of the time, it doesn’t make sense to provision and pay for unneeded per-second capacity. As a consumption-based option, serverless eliminates the concept of provisioned throughput and instead charges you for the RUs your database operations consume.

Check this video for a visual comparison between provisioned throughput and serverless:

Differences with provisioned throughput

Serverless containers expose the same capabilities as containers created in provisioned throughput mode. This means that you manage your resources and read, write and query your data the exact same way. Where serverless accounts and containers differ from those using provisioned throughput is:

Provisioned throughput Serverless
Maximum number of Azure regions per account unlimited 1
Maximum storage per container unlimited 50 GB
Throughput burstability unlimited moderate

Note: Some of these limitations may be eased or removed as serverless becomes generally available, and your feedback will help us decide! Please reach out and tell us more about your serverless experience.

When generally available, serverless will also offer different performance characteristics as explained in this article.

Use-cases

Because serverless is much more cost-effective in situations where you deal with light traffic and don’t need provisioned capacity, it naturally fits the following use-cases:

  • Getting started with Azure Cosmos DB
  • Development, testing and prototyping of new applications
  • Running small-to-medium applications with intermittent traffic that is hard to forecast
  • Integrating with serverless compute services like Azure Functions

To illustrate the advantages of using serverless for these scenarios, let’s take the example of a workload that is expected to burst to a maximum of 500 RU/s and consume a total of 20,000,000 RUs over a month.

  • In provisioned throughput mode, you would have to provision a container with 500 RU/s for a monthly cost of: $0.008 * 5 * 730 = $29.20
  • In serverless mode, you would only pay for the consumed RUs: $0.25 * 20 = $5.00

(not accounting for the storage cost, which is the same between the 2 modes)

Getting started

You must create a new Azure Cosmos DB account from the Azure portal to get started with serverless. When creating your new account, select Core (SQL) as the API type, then Serverless (preview) under Capacity mode:

Creating an account in serverless mode

Once your new serverless account is created, you manage your Azure Cosmos DB resources and data just like you would in provisioned throughput mode. The only difference is that you don’t have to specify any throughput when creating a container:

Creating a serverless container

We can’t wait to see what you will build on Azure Cosmos DB serverless! Get started today with the following resources:

18 comments

Comments are closed. Login to edit/delete your existing comments

  • Rehan Saeed

    Are the 5,000 RU/s and 50GB limits self imposed or limits of the technology? It would be great to see them removed. You hint that they may be removed.

    • Thomas WeissMicrosoft employee

      These are technical limits that we believe are suitable for dev/test activities and small apps. Indeed, we may increase them based on the feedback we’ll get from our users during the preview.

  • István Döbrentei

    It is awesome news, when is it be available the MongoDB API support?

      • Prashant Nagori

        Cassandra also coming in couple of months ? Will we be able to use in production ?

        • Thomas WeissMicrosoft employee

          Yes we’ll support all APIs – including Cassandra – very soon. Like any Azure preview, serverless is currently not covered by our SLA and is not recommended for production workloads until it goes GA.

          • prashant nagori

            Thanks we are waiting for Cassandra, Do you have any tentative date please ?

        • Thomas WeissMicrosoft employee

          (replying here as apparently I can’t reply to your last comment below!)
          We plan to extend serverless support to all APIs next month (October).

  • Jean-claude Quenaon

    Great news, do you have a date planned for release version?

  • Marco Kastrup

    Great news! I love CosmosDB. One question tho. Will it be possible to start with serverless to prototype the application and then switch to provisioned later when the app takes off and leaves prototype phase? Or do i have to make some hand made migration work?

    Cheers!

    • Thomas WeissMicrosoft employee

      Thanks Marco! For now you would have to migrate your data to a provisioned throughput account. We’re evaluating whether it will be possible to transform a serverless account into a provisioned throughput one at GA; if not, we’ll provide clear guidance on how to easily migrate your data.

  • Antonio J Dios García Martin

    Just to know if I’m correct. The 50 GB are per container. So I could have more than one container in the same database, or having more than one database insn’t?
    My idea would be split the data amond years into different container so I wouldn’t get the 50 GBs. would it be possible?

    Wishing the oficial release