When to use a serverless database, and when NOT to

Serverless databases are the future. The rise of the serverless database means that developers can enjoy the benefits of traditional relational databases — ACID compliance, familiar SQL, etc. — together with the advantages of serverless databases — elastic scaling, consumption-based billing, bulletproof resilience, etc.

If you’re not already up to speed, here’s a quick overview of what serverless databases can bring to the table:

None of this is hypothetical. Here at Cockroach Labs, we’ve just launched our own serverless database: CockroachDB Serverless, including a generous free tier that means you can spin up your own serverless database right now, for free.

But why would you want to? What are serverless databases actually good for, and when might a serverless database not be the best choice?

When to use a serverless database:

When you need automated elastic scaling

Any database can “scale,” in the sense that it’s always possible to throw more engineers and machines at a problem. But that approach is expensive, inefficient, and it doesn’t really work for spiky workloads or “surprise” scaling incidents like having your application suddenly go viral.

Serverless databases solve this problem because they can scale up and down automatically, reacting almost instantly to changes in demand. When traffic to your application is light, your serverless database will scale down so that it consumes fewer compute resources (and thus costs you less). When traffic spikes, it scales back up to meet the new demand without impacting application performance.

Automated scaling is beneficial for any business, but it’s particularly critical for businesses with spiky or unpredictable workloads. Instead of having to try to predict the future when you’re doing capacity planning, you just spin up a database cluster and let it take care of the scaling for you.

When you need to minimize costs

Traditionally, database servers were consumed machine by machine. In other words, you paid for as many servers as your workloads required. If you were not using all of the storage and compute capacity of those machines you were paying for, too bad. No refunds.

The reverse was also true — if you were paying for a set number of machines and your workload spiked beyond their capacity, your application’s performance would suffer.

Serverless databases solve both of these problems by billing you for your actual storage and compute usage, not by the machine. This is made possible by using a serverless architecture (more details here) in tandem with the seamless elastic scaling we just talked about.

The resources your database is allocated scale up and down automatically with demand, and so do your costs. CockroachDB Serverless also enables you to set monthly resource limits to ensure that you never exceed your budget.

The bottom line is that for many users, serverless databases offer more reliable database performance at lower cost. Serverless databases aren’t always going to be the optimal choice for every application. But because of this only-pay-for-what-you-use architecture, they are an effective way to minimize database costs for a wide range of workloads.

It’s also important to remember that the cost savings often go beyond just what you see on your bill…

When you need to minimize ops

Traditionally, businesses with transactional database workloads (i.e., most businesses) had to choose between two rather unappealing options:

Easy scale using a NoSQL database, but at the cost of losing transactional consistency and having to learn a new proprietary query language, or Maintain transactional consistency and familiarity of SQL, but spend considerable operational effort to scale using manual sharding.

Serverless databases such as CockroachDB Serverless give developers a way out of this choice. With automated scale and resilience, it can provide the ops-free scaling experience of NoSQL without losing ACID transactions and the other advantages of SQL databases.

In practical terms, what this means is that you and your team can spend less time worrying about the database and more time building your application. This makes serverless databases an especially good choice for any development team that wants to focus on development and remove the burden of database ops.

When you’re testing, experimenting, or evaluating

Serverless databases are great for lightweight applications, prototypes, test and dev environments, side projects, etc. because they’re self-serve, fast, and — at least in the case of CockroachDB Severless — free.

Seriously, you can sign up for an account, spin up a cluster, and get it connected to a simple app in about five minutes, with no credit card required:

The entire process is also completely self-serve. This makes it great for experiments and side projects because it allows you to “kick the tires” and work out any bugs before committing a dime. Or, you can make it part of your regular prototyping process, or use it for testing in your CI pipeline.

When you expect on/off usage patterns

CockroachDB Serverless specifically can be a great choice for any application that’s likely to generate on/off usage patterns — periods of dormancy interspersed with periods of higher activity levels.

There is an important caveat here, though: this isn’t true of all serverless databases. When a dormant database has to be spun back up, latency caused by that “cold start” can lead to a poor user experience.

However, CockroachDB Serverless specifically avoids the cold start problem with a unique architecture that allows a dormant database to consume zero compute resources but still be available instantly when a request comes in.

This makes it an optimal choice for any application that’s likely to see on/off usage patterns, since it ensures you’re not consuming (or paying for) any compute resources when they’re not needed.

When you want to future-proof your application

Small companies and startups may not need features like automated scale and resiliency in the near-term. Many companies can and do get by with “old school” setups like single-instance Postgres or MySQL databases. But just because you can doesn’t necessarily mean you should.

If you hope to scale in the long term, there’s really no reason to put off the process of migrating to a cloud-native, elastic scaling serverless database. As your application grows in complexity, the process of migrating — or trying to retrofit cloud and scaling features into a database that wasn’t really built for either of those things — only becomes more painful. It’s much easier to start from the beginning with a database that can scale as your company grows, even if you don’t anticipate much need to scale in the first few years.

It’s also worth mentioning that choosing a next-generation cloud database such as CockroachDB Serverless can be helpful in attracting talented engineers. The best engineers want to work with new, exciting technologies. Giving devs a chance to work with a serverless, distributed SQL database such as CockroachDB can set your job postings apart from the crowd of MySQL, Postgres, and Oracle options.

When NOT to use a serverless database:

Serverless databases are great, but they aren’t always the right solution. Here are some circumstances where choosing a serverless database might be a mistake:

When you need control over the hardware

A serverless database is a managed solution, meaning that you don’t have to worry about details like precisely how your data is stored, or how the automated scaling works. For many developers, that simplicity is a selling point, as it allows them to focus on building their applications.

But it does mean that you don’t have complete control over some of the details, and since it’s cloud-based, you don’t have control over the hardware. This can rule out serverless databases as an option for some companies, who may need an on-prem solution where they can control the hardware (for security or regulatory reasons, for example).

When you need a deep featureset

Serverless databases are amazing, but they’re also relatively new. That means that serverless databases right now tend to come with fewer features than their non-serverless counterparts. In the current beta, for example, CockroachDB Serverless doesn’t currently support some of the multi-region features found elsewhere CockroachDB.

Of course, this is only a temporary disadvantage. Pretty soon, serverless databases will reach the level of maturity and feature depth that’s available in non-serverless offerings. But if you need a database with multi-region capabilities right now, you may be better served by a non-serverless option such as CockroachDB Dedicated.

When security concerns rule out multi-tenancy

CockroachDB Serverless and other multi-tenant serverless databases certainly include security measures that isolate tenants activities and their data from one another. But at the end of the day, tenants are still sharing the same machine, which means that a serverless database usually isn’t the best choice for workloads that require a high level of security.

For those high-security workloads, a dedicated solution such as CockroachDB Dedicated is a better choice, providing many of the same advantages available in a serverless database

When another option offers better performance or costs less

While serverless databases are the best choice for many use cases, there’s no “perfect” database solution that’s optimal for every possible use case/workload. There are cases where a solution like CockroachDB Dedicated or CockroachDB Self-hosted is going to be preferable to Serverless.

But of course, one of the wonderful things about Serverless is that it’s available self-serve, for free. So while we can’t cover every possible use case in this article, you can spin up a free cluster and experiment for yourself to see whether a serverless database is the right solution for your team.