, 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 .
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 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.