Azure Cosmos DB, Microsoft’s cloud-scale distributed database, is designed to offer the APIs and the storage model you need for your applications. Want a NoSQL database? Use the MongoDB or Cassandra APIs. Need to work with graph queries? Use the Gremlin API. Azure’s own table storage APIs? They’re in there too. There’s even the option of using SQL.
But that’s only the outside of Cosmos DB, its connection to the rest of your application. In many cases you’ll need to add more code to manage your data and provide basic processing inside the database. Traditional databases offer stored procedures and triggers to manage this, running server-side code close to your data.
Going server-side in Cosmos DB
It’s no surprise that Cosmos DB supports server-side code, with a built-in set of JavaScript APIs that run transactional code inside the database, much like your SQL Server stored procedures. However, building and running those stored procedures is rather different and requires some thought. You’re no longer working with one database on one server (or at most, a small local cluster). Now you’re working with distributed stores that may be continents apart and use new consistency models. These models are more predictable than eventual consistency but don’t offer the locks that are required by strong consistency models.
At the heart of Cosmos DB’s stored procedures is its integrated JavaScript query API. Procedures get access to standard database operations to create new items and read, update, delete, and query existing items. They work inside Cosmos DB containers and are registered to specific collections in your database.
