All databases are ultimately just applications. Fundamentally, then, the definition of a serverless database is any database that embodies the core principles of a serverless application:
No server management
Automatic elastic scale
Built-in resiliency and fault tolerance
Consumption-based billing
Instant access and always available
The exact flavor of the database itself doesn’t matter, whether CRM app or RDBMS or OLAP or whatever else: Any database calling itself serverless must possess these five fundamentals. While there are many different types, the most complex to deliver is a relational database that provides referential integrity, joins, secondary indexes, etc., as well as guaranteeing ACID transactions. This is why serverless relational databases must meet additional requirements to earn the right to use the name “serverless.”
Every application requires data, and SQL is the language of data. If you want to interact with data, at some point you’re going to run into at least a little SQL or one of its dialects. Delivering the elegance of SQL may not be a requirement of every serverless database, but it is cardinal to relational databases. If you want a serverless relational database, it only makes sense that it’s a distributed SQL database.
So what does a true serverless SQL database look like? A true serverless SQL database adds three more essential requirements:
Distributed architecture
Geographic scale
A simple SQL API in the cloud
What happens when we assemble all nine of these elements together? We have a database that lets you achieve native scale and global coverage without the complexity of working with a distributed database — while working with the straightforward familiarity of SQL.
What are the features of a serverless SQL database?
Why are these requirements so important, how do they work together in a serverless SQL database, and — most importantly — how do we know these features when we see them?
Let’s look at the fundamental requirements for serverless applications and how they are specifically delivered in a serverless SQL database.
No server management.
Standard disclaimer: Despite the name, serverless applications do rely on servers. Provisioning, capacity planning, scaling, maintenance, updates — all that is still happening, for sure, but now it is behind the scenes. The important part is that we, as users, aren’t the ones doing it. All we are in charge of is logic. I mean, does any dev sincerely enjoy managing their services and apps?
2. Built-in resilience and fault tolerance.
A true serverless SQL database can survive node, zone, and even region outages, so you never need to worry about your data being unavailable. It will survive backend failures and guarantee data correctness even when these issues happen. It can even allow you to implement online schema changes and roll software updates across multiple instances of the database, all without issue and while always remaining available. It eliminates both planned and unplanned downtime.
3. Automatic elastic scale.
A serverless SQL database scales up and down automatically to meet demand. That includes scaling all the way down to zero when the database isn’t being used, and spinning up again instantly when a query comes in. You don’t need to worry about whether your database can handle a sudden spike in reads and writes because scaling automatically just happens.
4. Consumption-based billing.
True serverless databases automate the elasticity of data demand, so you pay only for the resources you use when you use them. Consumption-based billing keeps costs as low as possible. Furthermore, serverless databases also allow you to set limits so that you never overrun your budget.
5. Distributed architecture.
A serverless database also signals inherently distributed database architecture. Distributed SQL is a single logical database deployed across multiple physical nodes in a single data center, or across many data centers. To deliver on the elastic scale and native resilience that are two of the fundamental principles of serverless applications — which includes databases — a true serverless database by definition needs to be distributed.
6. Geographic scale.
Any serverless database should also scale geographically. A true serverless SQL database allows for truly multiregional data and automated geo partitioning, moving data dynamically around the globe. This lets developers both minimize latency and solve regional data domiciling requirements (such as GDPR) easily in the data layer — instead of trying to handle this in the application layer.
7. A simple API in the cloud
SQL is the language of data and the default for all application logic. Developers shouldn’t need to learn a new language just to use a database. Interacting with your database should be as easy and familiar as a simple REST API and your favorite SQL dialect.
(Requirement number 5 is bound to stir up some controversy. There are SQL databases that claim to be serverless, even though they are not distributed. Instead, they’re basically thousands of Postgres shards that SREs manually add and remove. There goes your automation. Furthermore, they’re shards — they don’t talk to each other! — so there also goes your inherent resilience and scalability. Ultimately, a serverless SQL database means never having to say, “I sharded.”)
So what does a true serverless SQL database ultimately allow you to do?
Serverless SQL Benefits
Serverless SQL is the next logical evolution of the database and the future of the way we manage data in the cloud. This means that, beyond the six fundamentals above, a true SQL database must deliver even more:
ACID transactions. You should never have to sacrifice consistency for scale. A serverless SQL database must provide ACID-compliant transactional consistency without sacrificing speed, no matter what scale you’re operating at. Guaranteed atomicity and consistency, serializable isolation, persistent data — all guaranteed correct (and good enough for nuclear codes).
Geo-replication. A serverless SQL database provides data durability through geo-replication: creating or updating data in a primary location and then asynchronously replicating it to multiple distributed locations so that the same data exists (and is backed up) independently in all locations.
Multi-cloud capability. A true serverless SQL database allows the operational flexibility of simultaneously deploying to multiple clouds. This lets you minimize latency without compromising availability, even in the face of cloud provider service failures.
Ultimately, when we put all these things together, developers get a database that takes the operational complexity out of database deployment and operations, so that we can get right to work building cool stuff.
What can a serverless SQL database do for developers?
For the developer, the value is the simplicity and ease of the platform. How do I just interact with this thing without even having to deal with making sure it’s on or making sure it scales, making sure it’s deployed in the right places?
The value that serverless promises — minimizing repetitive and manual work around managing servers and infrastructure and background (non-business-value) parts of any application — is incredible, though for a long time it wasn’t clear when that future would fully arrive.
Now we are another step closer to that serverless future where a serverless SQL database can abstract away much of the complexity of a distributed database into a simple REST API in the cloud. A future that provides developers with automated scaling, resilience, and transactional consistency with very little operational overhead and a consumption-based billing model that minimizes and protects costs. And interestingly, though SQL is usually synonymous with tables, rows and joins, these benefits can also extend to analytic data.
Fun fact: serverless SQL isn’t only for relational databases!
Fundamentally, a serverless SQL database simply lets you process distributed data using SQL language without operating the servers, managing maintenance and capacity planning, etc. So it is possible to apply serverless SQL to analytic data by running SQL queries on unstructured data in, say, a data lake or blob storage — without the need to first inject the data into a NoSQL database, like MongoDB or Cassandra, typically chosen for analytic data workloads. Serverless SQL is valuable for the fast and flexible insight it can provide into analytic data: For example, interacting with offline data with no need to build a pipeline, or examining new data just sunk into storage before it is transformed and saved to its dedicated database.
No matter what flavor your data may be, a serverless SQL database unites the simplicity of serverless, the reliable familiarity of a traditional RDBMS, and the global scale of the cloud. Serverless SQL removes the operational complexity of distributed architecture and puts you in charge of just one thing: your data. A serverless SQL database reduces and automates operational overhead so developers can just get to work on what really matters: the data that drives, and differentiates, our applications.
Ready to try Serverless SQL for yourself? Start instantly with CockroachDB Serverless!
