Last week I launched a new chat for all subscribers of The Serverless Mindset. It’s a great place to ask questions and suggest topics for future posts. I invite you to check it out and let me know what you think! - MT

Choosing the right database for your serverless application can seem like a daunting task.

First of all, there are a bunch of different options on AWS alone. If you search long enough, you’re bound to find lots of helpful comparison articles that show you the pros and cons of each database, but that often doesn’t tell you much that you didn’t already know.

Secondly, there’s the question of prior experience. Let’s say I know my way in and out of MongoDB, having used it extensively in previous projects. Should I use whatever database everyone is saying is the best for serverless? Or should I stick with what I already know?

Let’s try and make the database choice a little easier.

Specific vs Generic Use Cases

First of all, we should differentiate between specific use cases and more generic ones.

If I’m trying to build a search functionality, then it’s a specific use case: I need a database that is fit for search. That, in the world of AWS, means using OpenSearch. Similarly, if I need to build a ledger-like system, there is a specific database for that and it’s QLDB.

A generic use case, on the other hand, is one where you could just as well use a relational database (like PostgreSQL) or a NoSQL one (like the previously mentioned MongoDB).

In a generic use case, I could use some of the structure and transactionality granted by relational databases, but I could also do with some of the flexibility that NoSQL offers. In other words, either paradigm will work and whichever way I go, I’ll have some tradeoffs to make.

In my experience, these generic use cases are far more common.

But this is also why reading about the pros and cons of each database is not particularly helpful. In fact, it’s frustrating!

Databases for Generic Use Cases

When it comes to Serverless on AWS, there are essentially two options (but I’ll add a third!) for generic use cases.

These options are:

1. DynamoDB

2. Aurora Serverless

3. DocumentDB

If you’re looking at option #3 and thinking “that’s not serverless!”, you’re right! But I think it should be on that list, and I’ll explain why in a moment.

DynamoDB is a key-value datastore. It’s extremely powerful, virtually infinitely scalable, and it requires as little maintenance as you could possibly imagine. Once you get the hang of it, it’s a pleasure to work with and it’s an operational dream.

Aurora Serverless is a relational database. It’s compatible with both MySQL and PostgreSQL. It demands slightly more work as far as set-up and maintenance are concerned. But, again, once you get it going, it’s relatively hassle-free.

Lastly, DocumentDB is a MongoDB-compatible database. It supports most of MongoDB’s original syntax. It’s fully managed but it’s not properly serverless since it requires setting up compute instances, so there’s more operational overhead involved.

What Should I Use

First of all, we should talk about prior experience.

If I or my team have prior experience using MongoDB, then DocumentDB is a good option. I say this somewhat controversially: DocumentDB is not properly serverless and it will inevitably take away some of the benefits of a fully serverless stack. But it’s a fully managed database that should mostly work with little to no maintenance. If the team knows Mongo well, going through the pain of learning a different database (unless there are reasons for doing so) is not worth it.

If my team has previous experience using relational databases, then Aurora Serverless should quite possibly be the go-to choice. Setting up Aurora Serverless (v1 or v2) is not terribly hard and there’s something reassuring about relying on good ol’ SQL and well-structured relational tables.

In all other scenarios (including when the team’s prior experience is mixed) then DynamoDB is the way to go. Dynamo is a truly serverless database and it will bring to light all of the glorious benefits of serverless.

Unfortunately, getting to grips with Dynamo’s query syntax and best practices for data modelling can take some time. The investment is totally rewarding though. I have used DynamoDB on multiple applications at a very high scale for years now.

Even if I decide to start out with either DocumentDB or Aurora Serverless, it’s worthwhile investing in the team’s knowledge of DynamoDB so that it can be used in upcoming projects.