Why Serverless SQL could be a game changer

Serverless for computation

Serverless solutions such as AWS Lambda, Azure Functions, and Google Cloud Functions have been out there for several years now. For companies that have a significantly long prototyping stage, B2B, or B2E companies with predictable and somewhat low traffic patterns, Serverless has been the ideal solution for their needs.

It allowed developers to concentrate on the product instead of the infrastructure, during times when there was no real reason to worry about scaling or performance issues.

The only thing that still needed to be solved was the database.

Note: The following article lists Amazon Web Services (AWS), Microsoft Azure, and Google Cloud (GCP) solutions to keep things short. We know of the many marvelous cloud providers out there, and we are always happy to hear about new ones.

Database solutions for Serverless stacks

Serverless but NoSQL

That includes the likes of AWS DynamoDB, Azure Cosmos DB, or GCP Bigtable. These solutions are truly Serverless in that for predictable usage patterns they’re likely to be the most cost-effective (and indeed at times cost nothing at all).

The issue with these solutions has always been the requirements. The vast majority of applications are written with SQL in mind (either MySQL or PostgreSQL). Rarely are they written for MongoDB and nearly never are they written for the solutions mentioned above. Integrating the likes of DynamoDB into your existing stack is very likely to include a significant learning curve as well as major changes to the way your application handles data. It’s also likely to require a rethinking of your usage patterns and remodeling of the existing data structure.

It still doesn’t include the fact that these tools need to be learned from scratch. For example, DynamoDB table designs are a different animal than what you’d find in MySQL or PostgreSQL.

SQL without Serverless

This one is likely to be the most common solution. An instance of AWS RDS, Azure SQL, or Google Cloud SQL is created to manage the database of the Serverless stack.

Alternatively, a self-managed database is created under a VM. That is clearly the most straightforward solution, but far from being the most cost-effective.

SQL and somewhat Serverless

That includes AWS Aurora Serverless or Azure SQL Serverless.

At this point, it seems that Google Cloud doesn’t offer a somewhat-Serverless SQL solution.

We define these solutions as “somewhat Serverless” as they only use an auto-scalable cluster of VMs to manage the database.

That means that during idle times the cluster indeed scales to zero cores. The pricing, however, is not measured by storage and calls which is why we don’t categorize these solutions under “truly Serverless”.

SQL and truly Serverless

Between the 3 Cloud Providers that we’ve mentioned so far, not a single one is currently providing truly Serverless SQL hosting. Last October, a team at Cockroach Labs was able to release a solution that checks all the boxes required for it to be called truly Serverless.

For many architects, keeping within their existing Cloud provider reduces overhead and allows for faster integration. At times it could also be a strict requirement. That means that in most cases, architects are still waiting for a truly Serverless SQL solution from one of the major 3 providers.

However, as this technology is still new and under development, we’ll likely see more truly Serverless SQL offerings in the not-so-distant future.