Why You Shouldn't Use An ORM With DynamoDB

ORMs simplify your life.

I get it.

They let you use a programming language to interact with your database instead of writing raw SQL queries.

With NoSQL the equivalent of an ORM is an ODM (Object Document Mapper).

But this convenience is scoped to working with relational databases.

Not DynamoDB. Let's understand why.

Why Not To Use ORMs/ODMs

ORMs makes sense to use with relational databases because there's a single way to model data. Each data entity is stored in its own table and related data is queried using foreign keys.

With DynamoDB this is very different. Best practice dictates all of your data entities to be combined into one single table. As well, fetching related data is drastically different in DynamoDB. That is done with the primary key design as opposed to a simple SQL query.

Another reason to avoid ODM's is this:

With relational databases, you can often have large SQL strings and ORMs removes the need for these complex strings.

With DynamoDB, you cannot have large and complex strings.

DynamoDB provides an API (the AWS SDK) which you can use to perform a limited set of read/write operations.

Here's an example:

Fetching data with complex filtering can be performed like this:

const params = {
      TableName: "my-db",
      KeyConditionExpression: "pk = :pk AND begins_with(sk, :sk)",
      ExpressionAttributeValues: {
        ":pk": { "S": `u#${userId}#posts` },
        ":sk": { "S": `p#2025` },
      },
      Limit: 20,
  };        

This query code will fetch user posts and can filter them down by year (p#2025). Since we rely on strong data modeling in DynamoDB to enable efficient filtering, there is much less effort on the query side (even though there is much more effort in the data modeling phase).

Consequently, the query string does not grow as much as with SQL queries.

Using an ODM in DynamoDB will likely do the same work the AWS SDK performs when interacting with the DynamoDB API.

Some Exceptions

There are some exceptions to this "no ORM rule".

The first one is the Document Client that AWS provides with the Node JS SDK.

Here's what the Document Client does for you.

Rather than writing the attributes with the verbose DynamoDB syntax such as the following:

Item: {
  name: { "S": "John" },
  email: { "S": "[email protected]" }
}        

We can use the Document Client and simply write out our attributes using standard Node JS syntax:

import AWS from "aws-sdk";
const docClient = new AWS.DynamoDB.DocumentClient();

Item: {
  name: "John",
  email: "[email protected]"
}        

This makes our lives a lot simpler when writing a lot of DynamoDB queries.

The second exception is the Jeremy Daly's DynamoDB Toolbox for Node JS.

It is not an ORM, it only helps you define entity types in your application and map those to your DynamoDB table.

Conclusion

Using these libraries are much more beneficial than using ODMs with DynamoDB.

However, they don't perform all the work for you, you still need to be aware of solid data modeling and understand how to query your tables data efficiently.

Using these "helper" libraries only make your work interacting with DynamoDB's API easier and quicker, so you want to treat them as a helping hand only.

?? My name is Uriel Bitton and I hope you learned something in this edition of Excelling With DynamoDB.

?? You can share the article with your network to help others learn as well.

?? If you're looking for help with DynamoDB, let's have a quick chat here.

?? I hope to see you in the next week's edition!

References

1. The DynamoDB Book. Alex Debrie. April 7, 2020. https://www.dynamodbbook.com/. This article was directly inspired by The DynamoDB Book.