An Introduction to DynamoDB

This is the first post in a series covering everything I have learned about DynamoDB. Before we get into the details, you need to understand a few fundamental concepts.

#What is DynamoDB?

DynamoDB is a fully managed NoSQL database service provided by Amazon Web Services (AWS).

It allows you to store and retrieve data in a flexible, highly scalable, and low-latency database capable of handling millions of requests per second.

DynamoDB delivers fast, predictable performance with seamless scalability and high availability. It supports automatic scaling, encryption, backup and restore, and global tables for multi-region deployment.

#OLTP vs OLAP

DynamoDB is built for OLTP (Online Transaction Processing). It can handle certain OLAP (Online Analytical Processing) use cases, but it is not competitive with purpose-built OLAP databases like Amazon Redshift or Google BigQuery.

If you pick the wrong database for your workload, you will pay for it. Understanding the distinction between OLTP and OLAP is non-negotiable.

• OLTP -- Real-time transaction processing.
• OLAP -- Complex data analysis and reporting.

Let us make this concrete with examples.

#OLTP Example

Consider an e-commerce website processing orders in real-time. The database must be optimized for fast reads and writes to handle a high volume of transactions.

In SQL, this looks like an INSERT:

INSERT INTO orders (customer_id, order_data, total_amount)
		VALUES(123, '2023-04-07', 500.00);

Or an UPDATE to customer data:

UPDATE customers SET name = 'Ahmad Mayahi' WHERE customer_id = 123;

#OLAP Example

A retail chain needs to analyze sales data to determine which products perform well. Analysts need to retrieve and aggregate large volumes of data for business decisions.

SELECT
	product_id,
	SUM(sales_amount) AS total_sales
FROM
	sales_data
WHERE
	date BETWEEN '2023-01-01'
	AND '2023-03-31'
GROUP BY
	product_id;

Another example -- calculating the number of unique customers and average order amount per country:

SELECT
	country,
	COUNT(DISTINCT customer_id) AS unique_customers,
	AVG(order_amount) AS average_order_amount
FROM
	orders
	JOIN customers ON orders.customer_id = customers.customer_id
GROUP BY
	country;

The rule of thumb: if you are inserting, updating, or deleting individual records, that is OLTP. If you are aggregating, joining, and analyzing across large datasets, that is OLAP.

#Data Modeling and Access Patterns

DynamoDB requires you to think about database design differently than you would with a traditional RDBMS. You need to abandon your relational database assumptions entirely.

With SQL databases, you can run any type of query without limitations. With DynamoDB, you can only query data based on the primary key and cannot perform complex queries or joins the way you would in SQL.

You can model relationships in DynamoDB, but the approach is fundamentally different. DynamoDB uses "denormalization" -- you embed related data within a single item or partition rather than splitting it across multiple tables. This makes data modeling more deliberate, but it enables faster and more scalable data access.

#A word about MySQL

You might wonder why MySQL appears in a DynamoDB post. The reason is straightforward: most developers default to MySQL for their Laravel projects, and that choice has consequences.

MySQL is not designed for OLAP workloads. It has real limitations when handling complex analytical queries on large datasets.

If your aggregation queries are still slow despite indexing and optimization, the answer is simple: MySQL was never built for OLAP.

This is a deep topic on its own. Oracle has launched MySQL Heatwave, an analytics engine for MySQL. If you want to stay in the MySQL ecosystem but need analytics performance, Heatwave is worth evaluating.

Read more about MySQL Heatwave.

#Real-world use cases of DynamoDB applications

Despite its constraints compared to RDBMS, DynamoDB excels in specific scenarios. Here are real-world examples.

This list is based on the DynamoDB customer's page.

#Social Media (Snapchat)

DynamoDB stores user profiles, social graph data, and activity streams for social media platforms. Snapchat uses DynamoDB to exchange hundreds of millions of messages daily.

The access pattern is straightforward: retrieve messages by primary key. That is exactly what DynamoDB does well.

#Cloud Storage (Samsung Cloud)

Samsung Cloud uses DynamoDB as a metadata index for voice recordings, notes, and contacts stored in Amazon S3. According to JeongHun Kim, Database Engineer at Samsung Cloud, DynamoDB was chosen for its fast performance, durability, and scalability. Migrating some workloads to DynamoDB Standard-Infrequent Access tables reduced costs by over 30% with no impact on performance, durability, or scalability -- and no code changes were required.

#Summary

• DynamoDB is a fully managed NoSQL database built for high-throughput, low-latency workloads on AWS.
• It is an OLTP database -- if you need OLAP, look at Amazon Redshift or Google BigQuery instead.
• Data modeling is fundamentally different from relational databases; you must design around access patterns and use denormalization.
• MySQL is not an OLAP database either -- if your aggregation queries are slow, the problem may be the tool, not the query.
• DynamoDB shines in high-scale, simple-access-pattern workloads like messaging (Snapchat) and metadata indexing (Samsung Cloud).

In the next post, we will cover the fundamental principles of DynamoDB.