Introduction to serverless databases

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 should eliminate 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?

What is a serverless database?

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. 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.

A litmus test for true serverless databases

Below is a litmus test to use when evaluating databases claiming to be serverless. A true serverless database must have:

• Nothing to provision or manage
• Zero capacity planning, with infinite scale
• Usage-based consumption model
• Ready with a single API call
• No planned downtime

Note: This list was modified expressly for serverless databases but is based on the more general Serverless Litmus Test that Khawaja Shams and I 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.

What makes a truly serverless database?

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

Nothing to provision, nothing to manage

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!

Zero capacity planning with infinite scale

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.

Ready with a single API call

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.

Usage-based consumption model

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.

No planned downtime

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.

Examples of serverless databases

Below is a list of a few databases that present as serverless. We will leave it to you to use the litmus test to know whether they are genuinely serverless.

• Fauna is a truly serverless, document-relational database designed for modern applications, providing developers with effortless scalability and global availability without infrastructure management. It offers a flexible, developer-friendly API that supports complex queries and ACID transactions, ensuring data consistency and reliability. With support for both structured and semi-structured data, Fauna offers a robust operational database that supports a wide range of use cases and can evolve with your application. Multi-Active reads and writes and automatic distribution enable your application to scale without the complexity of manual sharding or replication.
• Amazon Aurora Serverless is a proprietary AWS service compatible with Postgres and MySQL, which means you can connect to your Aurora database as if you’re connecting to Postgres or MySQL. It is optimized for and only runs in AWS.
• MongoDB Atlas Serverless is a managed, cloud-based database service that simplifies the deployment and scaling of MongoDB clusters. It offers built-in features like automated backups, real-time performance monitoring, and advanced security. For a comparison between Mongo and Fauna, visit this page.
• Google Firestore is a serverless document database providing direct web, IoT, and mobile app development access. It’s highly scalable with no maintenance window and zero downtime.
• Amazon DynamoDB is a managed key-value NoSQL database service built with scale in mind. DynamoDB integrates well with other AWS services, such as Lambda, EventBridge, API Gateway, and Step Functions. For a comparison between DynamoDB and Fauna, visit this page.
• CockroachDB, offers several deployment options of its relational database, including a serverless version. It offers an elastic and robust data architecture distributed globally to help developers rapidly develop apps. It is a single Postgres instance in many aspects.

Discover the key differences between popular serverless databases with our comparison guide. Furthermore, 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.