Since the advent of cloud computing more than a decade ago, many have waited for a fully cloud-based, elastic database that could dynamically expand (and even shrink) its footprint and eliminate the significant operational overhead of maintaining a production database system.
Truly elastic cloud-native databases have emerged – for example, Amazon’s DynamoDB and Microsoft CosmosDB – but even now that we’ve passed the tipping point of the cloud database, the majority of cloud-based databases run the same software as their on-premises counterparts.
A modern distributed database platform like MongoDB or CockroachDB can easily run as a fully managed cloud service. And the advantages are obvious; When you buy a MongoDB Atlas service or a dedicated CockroachDB cloud service, you get a high-performance database cluster that runs on a dedicated cloud infrastructure, but your operational overhead is largely eliminated. It’s good business. However, this type of “dedicated” deployment does not quite match what the “elastic” cloud originally promised. In particular, you have to pay for the hardware hosting your cluster even when no workload is running.
Serverless cloud offerings
To bring us closer to the ideal of a fully resilient cloud database platform that works only for what you use, both MongoDB and CockroachDB recently announced “serverless” cloud offerings – and you can bet the other database vendors will will be quick to follow.
With a serverless offer, you really only pay for what you use. Of course, databases are hardly stateless. So when you store terabytes of data, you incur storage costs regardless of usage, but you only pay for CPU and I / O when you run workloads.
Both MongoDB and CockroachDB are calculated in the form of abstract units – MongoDB uses Read and Write Processing Units (RPUs and WPU), while CockroachDB uses “Request Units”. Both correspond roughly to a very simple database query – for example, searching for a single line or a document using an index.
Under the hood, both serverless offerings use a common tenancy architecture. In the case of CockroachDB, the data from each serverless database is stored on shared storage nodes. As the workload requirements increase, CockroachDB starts processing nodes to do SQL and transaction processing. MongoDB takes a similar approach. And providers provide you with a guaranteed free number of request units per month.
The advantages of the serverless approach are very significant for applications with variable workloads – like almost all. In existing offerings, you configure enough resources to handle your peaks – which usually means wasting money during the troughs.
Serverless may not be for everyone, however. In a serverless deployment, your application shares some physical resources with other serverless users. In particular, a single storage node contains data from multiple users. Of course, you won’t be able to see data from other users, but some organizations with highly sensitive security needs may find this “co-tenanting” unacceptable.
This co-tenanting also allows the possibility that a “noisy neighbor” could interfere with your performance. In addition, your data in the cache memory can be replaced by data from other clients during periods of low activity. When your application begins to boot up, it will experience a “cold cache” scenario in which the physical I / O rates are higher than normal.
In the serverless mode you “cap” your bill to a certain amount; If your resource usage exceeds this limit, you will be throttled to the performance limits of the free tier. There are of course ways to monitor and manage your resource usage, but if you don’t pay attention to your application usage, you might be surprised by an abnormally high bill or resource throttling.
However, these are minor drawbacks compared to the strong economic benefits of paying only for the CPU and memory you actually use, and the ability to ramp up resources quickly when you need them. I expect serverless offerings like MongoDB and CockroachDB to be very popular!