Azure Cosmos DB goes serverless

Azure’s Cosmos DB is one of the platform’s foundations, powering many of its key services. Designed from the ground up as a distributed database, it implements a set of different consistency models allowing you to trade off between performance and latency for your applications. Then there are its different models for working with data, from familiar NoSQL and SQL APIs, to support for Mongo DB’s API, to the Gremlin graph database query engine.

There’s enough in Cosmos DB to support most common cloud development scenarios, giving you a consistent data platform that can share data on a global scale. Microsoft often describes it as a “planetary-scale database,” a fitting description.

The serverless alternative to provisioned throughput

For all the benefits, Cosmos DB does have some downsides; not least its cost. Although there is a relatively limited free option, running it at scale can be expensive, and you need to take that into account when building applications around it. Budgeting for Cosmos DB request units is a complex process that’s hard to get right the first time, especially when you factor in scaling, either manually or automatically.

Microsoft has run a preview of a serverless option for Cosmos DB for a while now, based on its core SQL API. It’s an interesting alternative to the traditionally provisioned option. It only charges you when it runs a request and suspends your instance when there’s nothing happening. There will be additional latency in database operations, as your instance needs to spin up when it’s been suspended. Of course there’s a charge for storage, but that’s the same with any Azure database. The initial trial has now been expanded to all of the Cosmos DB APIs, with general availability not too far in the future.

Adding a serverless option to Cosmos DB makes a lot of sense for many types of workloads where you’re getting requests in small numbers and in batches. For a small workload with an irregular pattern of operations, a consumption-based pricing model makes a lot of sense—and can save a considerable amount of money over the long term as there is no commitment to provisioned throughput.

Costs are low: You pay $0.282 per serverless request unit, for as many as a million RUs in a billing cycle. If you need a more reliable server you can set up an availability zone, though this increases costs by 1.25x. That’s still a reasonable deal, and what you lose in predictability, you gain in lower costs. Storage costs remain the same for both manual and automatic provisioned throughput.

Getting started with serverless Cosmos DB

Jumping in is easy enough. Like a standard Cosmos DB account, you’ll need to provision it to a subscription and add your serverless instance to a resource group. Next choose the API you plan to use for queries, and when asked to choose a capacity mode, pick serverless rather than provisioned throughput. Finally link it to a region, remembering that you can only use serverless in a single Azure region; there is no option for geo-redundancy. You won’t be able to use it with the free tier, either.

Once your serverless instance is running you can use its APIs to load data and make queries. Like a standard instance of Cosmos DB, you can build JavaScript functions and triggers that run inside the database, as well as use its many different APIs to manage queries.

Serverless Cosmos DB should move out of preview soon, and is adding support for all its APIs, even for its recent Cassandra API. As it’s a public preview, you can set it up and explore its operation straight from the Azure Portal. While in preview there’s no support for ARM or other infrastructure as code deployment tools, though there should be once the service is generally available. You can’t automate configuration and deployment, so you won’t be able to use it as part of a CI/CD (continuous integration/continuous delivery) pipeline for now, as deployments will need to be manual.

Building code with serverless Cosmos DB

One place you should get a lot of value from serverless Cosmos DB is in parallel with Azure Functions. The two serverless environments work well together and are ideal for bursty, low-volume, event-driven applications. Serverless Cosmos DB can quickly ramp up from zero to 5,000 request units a second, so if you’re writing code that uses Functions to track error conditions or other alerts, it’s an option for quickly gathering and storing data.

Microsoft recommends using it as part of a development environment where you’re capturing data about the requests your full-scale application needs. As provisioning requests units is something of a black art, a serverless implementation running with all your in-database code is a useful development tool. You can set up an operational environment, run your tests, capture the number of requests used, and then use that data to provision throughput for a production deployment.

Understanding the serverless limitations

There are limitations to using a serverless Cosmos DB account. Perhaps the most important is that you don’t get access to multiregion deployments, as serverless accounts only run across a single region. It’s a limitation that makes sense: Multiregion Cosmos DB implementations need multiple instances running at the same time for inter-region replication and consistency. If serverless instances only run when they’re processing requests, then there’s no guarantee another region will be online to handle replication. As a result, there are changes to the Cosmos DB service-level objective for serverless instances, with writes expected to be 30ms or less, and reads 10ms or less.

The other key limitation is a maximum 5,000 request units per second. Again, that should be sufficient for most simple or development implementations, but it does require you to keep an eye on your applications and be ready to switch to a provisioned Cosmos DB instance if you regularly go over your limits. At the same time, each serverless container can only store 50GB of data and indexes. Microsoft provides tools in the Azure Portal to help monitor operations, as well as in Azure Monitor.

Adding a serverless option to Cosmos DB answers many questions about cost. For low-usage scenarios where you don’t need global coverage, it should be your first choice. Shift to using a provisioned throughput instance only when you’re able to understand your application’s request pattern and can budget accordingly.