Serverless computing allows developers to build and run applications without managing or worrying about the underlying infrastructure. Resources are automatically available based on demand, so you only pay for what you use. This means you can focus entirely on writing code and delivering features while the service provider handles all the operational details.

A serverless database combines the power of a database with the agility and simplicity of a serverless architecture. Using a serverless database eliminates the headaches of complex database management and enables you to seamlessly interact with your data through a straightforward cloud-based API. Many databases claim to be serverless or have a serverless option, but are they truly serverless? How does one judge these services to see if they are a truly serverless database?

To be truly serverless, a database must completely abstract any level of consideration for what, where, and how the service is running. It offers infinite scalability without capacity planning, automatically adjusting resources based on demand. Consumption is usage-based, meaning you only pay for the database operations performed and storage used, with no costs for idle capacity. A truly serverless database can be deployed instantly with just a single API call, and there is no planned downtime, ensuring continuous availability. This makes it an ideal choice for modern applications that require simplicity, scalability, and reliability.

This benefits teams by freeing developers from the complexities of managing database infrastructure, allowing them to focus entirely on writing and optimizing application code. The simplicity of starting with a single API call and the assurance of no planned downtime accelerates development cycles. These attributes ensure high availability, making building and deploying robust applications easier. With automatic scaling and usage-based pricing, there’s no need to worry about over-provisioning or under-provisioning, so there is no paying for unused capacity. You simply use capacity or don’t, as there is no ramping up or down capacity.

When can a database be considered serverless? A true serverless database must abstract every element of deployment and infrastructure management, from provisioning to scaling, allowing developers to focus entirely on building their applications. Here is a litmus test to use when evaluating databases claiming to be serverless.

A true serverless database must have:

Note: This list was modified expressly for serverless databases but is based on the more general Serverless Litmus Test that Khawaja Shams and Kirk Kirkconnell co-authored to give credit where credit is due.

Let’s dive into each of these tests a bit deeper and see what to look for.

Let’s review the above litmus tests to see what makes a serverless database and what fake serverless databases do and say.

A serverless database has no network, servers or instances, cluster, storage, etc. to specify, spin up, or manage. Sign up for the service, create a database with your data model (tables, collections, functions, roles, etc.), and start using it. You should configure backups for a production database, but that’s about it for the infrastructure you need to worry about.

Fake serverless databases may entail selecting instance types, creating or managing a cluster, picking node types, determining which Availability Zone the cluster nodes are in, and so on. That’s not serverless. It’s someone taking a database that isn’t serverless, putting lipstick on it, and unleashing their marketing and sales departments. Don’t fall for it!

With a true serverless database, there is no scaling up or down. There is no capacity to add that could take minutes to provision in a peak situation. In addition, there are no limits to scaling. The capacity is just there to be used or not.

Many fake serverless databases require you to pick instance types or the number of instances in a cluster, so you must actively add and remove capacity. The problem is you have to guess initially, then monitor and manage this over time. Choose poorly, and either you pay too much money, or you don’t have enough capacity to run, and you’re doing summersaults to swap to larger instance sizes. If you have enabled inter-regional replication, the burden of which nodes are where and what the database sharding looks like is all on you.

A true serverless database is just there, always ready and willing. You make an API call, and it answers immediately. There is nothing to spin up, no actions to compensate for cold starts, and no connection pools. Even better is when that API call can be over HTTPS, as you can call it from serverless edge functions (e.g., AWS Lambda@Edge, CloudFlare Workers, Vercel Functions, Netlify Functions, and more) with any modern programming language.

Fake serverless databases may still require things like connection pooling and fat clients. This makes your app code bigger and more complicated, takes more developer time, and is sub-optimal for most serverless functions, especially serverless edge functions. The larger size and connection pooling means that regardless of where your code is, the function needs more resources than it might with a genuine serverless database.

True serverless databases should not force upfront provisioned capacity. Mandating a predetermined capacity commitment places an undue burden on developers. A serverless database bases ongoing pricing on what you use. To put it another way, resource consumption is metered. Any other style of pricing, you risk going down the too much or too little capacity I mentioned earlier, which is sub-optimal.

Many fake serverless databases require predetermined capacity commitments because, despite appearing as a SaaS offering, they are often just provisioned single-user systems on the back end. Without knowing your exact needs, these systems are often provisioned large, leading to inflated costs through dramatic per-usage metering. Even if capacity commitments aren’t mandatory, they’re often presented as a tempting option for discounts. In contrast, genuine serverless databases operate on a multi-tenant system where the underlying cluster is already provisioned, meaning nothing needs to be set up expressly for you, and you only pay for the resources you use.

A true serverless database implements changes without planned downtime. One of the main points is that a serverless database needs to be available immediately when it’s called. You can’t do that when the database takes planned downtime. Any patch, new feature, or whatever is applied to the service, and the first a customer should hear of it is an announcement of that new feature, or they notice things just working better.

Some fake serverless databases require downtime to roll out a new version, feature, or patch. You get messages like, “Hey, your database will be unavailable for a software patch for an hour this Saturday night.” Just…no.

Embracing a truly serverless database can significantly reduce operational complexity, eliminate capacity planning, and empower developers to focus on innovation rather than infrastructure management. As you evaluate your options, be sure to apply the litmus test to distinguish between genuine serverless solutions and those that only claim to be. By choosing the right serverless database, your team can unlock faster development cycles, improved agility, and long-term cost efficiency.

Discover the key differences between popular serverless databases with our comparison guide, and understand how Fauna offers a true serverless database choice by exploring its unique features and benefits. For more in-depth comparisons of Fauna vs other serverless databases, check out Fauna vs. DynamoDB, Fauna vs. MongoDB Atlas, and Fauna vs. AWS Aurora Serverless v2.