DynamoDB

Rationale

DynamoDB is the database we use for storing all the business-related data in our [ARM][ARM]. The main reasons why we chose it over other alternatives are the following:

• It is a NoSQL database service whose premise is to be performant and scalable no matter the request traffic.
• It is a SaaS-oriented database since it does not require managing any type of infrastructure such as networks or servers.
• It complies with several certifications from ISO and CSA. Many of these certifications are focused on granting that the entity follows best practices regarding secure cloud-based environments and information security.
• It was designed to provide single-digit millisecond performance without having to worry about scalability or availability.
• It is accessed using a public API.
• It has a partition-based architecture, which allows it to handle hundreds of TiBs of data.
• Database designs can be versioned as code using NoSQL Workbench for DynamoDB.
• It supports pagination, which is essential for keeping applications performant when queries return too much data.
• It supports global secondary indexes, allowing us to add new access patterns as applications evolve.
• It supports classic on-demand backups, allowing us to have backups of all our data stored in the cloud.
• It supports Point-in-Time Recovery, which helps us restore tables to previous states in time by using incremental backups.
• It integrates with Redshift, partially allowing us to move data to our data warehouse.
• It supports local deployments, i.e., we can run DynamoDB on local machines. This is especially useful for ephemeral environments.
• All its settings can be written as code using Terraform.
• It is supported by Terraform state locking, which allows us to avoid race conditions when applying infrastructure changes.
• Its performance can be monitored via CloudWatch.
• It is supported by many programming languages, including Python.
• It supports encryption at rest, allowing us to easily keep stored data secure.
• It fully integrates with IAM, allowing us to keep a least privilege approach regarding authentication and authorization.

Alternatives

• Google Cloud Spanner: It is a Relational Database Management System (RDBMS), which means it is not as scalable and performant for web-scale applications. It requires managing infrastructures such as clusters, nodes and networks. Connecting it to other AWS services increased complexity. In addition, it had an unpredictable pricing model at the time.
• AWS RDS: It is an RDBMS, which means it is not as scalable and performant for web-scale applications. It requires managing infrastructures such as clusters, nodes and networks.

Note: > Azure Cosmos DB is another alternative. A review is pending.

Usage

We use DynamoDB for

• storing and retrieving all the business-related data in our [ARM][ARM];
• storing Point-in-Time Recovery backups of all our data;
• storing on-demand backups of all our data;
• keeping a versioned design of our database, and
• managing Terraform state locks for all our infrastructure modules.

Guidelines

• You can access the DynamoDB console after authenticating to AWS.
• Any changes to DynamoDB infrastructure must be done via merge requests.
• To learn how to test and apply infrastructure via Terraform, visit the Terraform Guidelines.
• Following AWS best practices, we use a single table design for our database.
• You can view the design with NoSQL Workbench for DynamoDB.