Serverless databases offer highly scalable, cloud-based data storage and retrieval without requiring you to provision CPU or storage ahead of time.
Serverless cloud computing services started with AWS Lambda, which lets you run code without provisioning or managing servers. AWS Lambda is an example of functions as a service, or FaaS, and other FaaS implementations quickly followed at Microsoft Azure and Google Cloud. Later, cloud providers started offering other services in serverless form. Serverless was a new way of thinking about cloud services, and in practice serverless architectures often cost a fraction of provisioning permanent server instances to run the same loads. When a request for a serverless service comes in, the cloud provider allocates an instance (virtual machine) or pod (a logical set of containers, usually managed by Kubernetes) to handle the request from its pool. When the serverless code exits, the allocated resources are returned to the pool. In general, you pay for the resources you use based on their CPU capacity, RAM allocation, and time active. Serverless functions and services can invoke each other, can invoke other services, and can write to shared file systems and databases. One of the biggest technical advantages of serverless functions is their extreme scalability: Unlike provisioned servers, which can easily be swamped by traffic spikes, new serverless function instances are launched for every event that needs them, and all instances automatically return to the pool when they are not needed. What happens when an appropriately sized instance (or pod) isn’t available in the pool when a request comes in? The cloud provider must create a new one. That causes some latency in handling the request. If latency is a problem for your use case, then you can pay to keep some functions initialized and hyper-ready to respond. AWS calls this Provisioned Concurrency; the other cloud providers use different names, but they all rely on keeping some instances pre-warmed to reduce latency. Serverless functions and services usually have high availability. If you are using a single server, virtual machine, or container to run a service, the probability of an eventual service outage from a machine or data center failure is high. Cloud providers generally maintain redundant compute capacity for serverless functions across multiple availability zones (data centers in different but nearby physical locations) in each geographical service region. In addition to serverless functions and services from cloud providers, there are many cloud-agnostic frameworks and SDKs for creating serverless apps. These include Kubeless, Pulumi, OpenFaaS, OpenWhisk, and Serverless Framework. According to Jim Walker of Cockroach Labs, a serverless database adheres to nine core principles: Principles 1 though 5 could be applied to any serverless service, but principles 6 through 9 are specific to global SQL databases. Number 9 appears to be biased in favor of distributed SQL databases such as CockroachDB, which is why I have added parentheses around that item.
