DynamoDB CRUD operations and Query vs Scan

1. DynamoDB CRUD operations and Query vs Scan

In this video, you'll learn how to perform CRUD operations, understand the critical difference between Query and Scan, and implement consistency models. Let's dive in.

2. The expensive mistake

Here's a real story: a developer needed to find a user by ID. They used Scan because it seemed simple: just scan the table and find the match. The problem is that Scan reads every single item. Their table had 1 million items, running this query 10,000 times daily. Monthly bill: $500 for what should cost pennies. The correct approach? Use Query with the partition key. It reads only needed items and costs 50 times less. Understanding Query vs Scan is critical for performance and cost. Let's learn how to do it right.

3. CRUD operations in dynamoDB

DynamoDB provides four basic operations. PutItem creates a new item or replaces an existing one: use when you have all the data. GetItem retrieves a single item using its primary key: your fastest read operation. UpdateItem modifies specific attributes without replacing the entire item: perfect for incrementing counters or updating fields. DeleteItem removes an item. All operations work on single items and require the primary key. But what if you need multiple items or don't know the exact key? That's where Query and Scan come in.

4. Query vs Scan: the critical difference

Query and Scan are fundamentally different. Query requires a partition key and only reads items in that partition: fast, efficient, and cheap. Scan reads every item in the table then filters: slow, resource-intensive, and expensive. The rule: if you know the partition key, use Query. If not, redesign your table or add a Global Secondary Index. Scan should be a last resort for small tables or infrequent operations like backups. Always prefer Query for production workloads.

5. Preventing race conditions with conditional expressions

Here's a common problem: two users update the same item simultaneously. Without protection, the second update overwrites the first, losing data. The solution is conditional expressions - specify a condition that must be true for the update to succeed. For example, 'update this user's email only if current email is [email protected]'. If another process already changed it, your update fails safely and you can retry. This prevents race conditions and ensures data integrity in distributed systems.

6. UpdateItem expressions: modifying attributes

UpdateItem uses expressions to modify specific attributes without replacing the entire item. SET assigns values: use it to update fields or create new attributes. ADD increments or decrements numbers atomically: perfect for counters like view counts or inventory. It also adds elements to sets. REMOVE deletes attributes from an item entirely. DELETE removes specific elements from sets. These expressions are atomic and efficient: you only send the changes, not the entire item. Combine multiple operations in one UpdateItem call for complex updates.

7. Pagination with Query and Scan

DynamoDB returns maximum 1MB of data per Query or Scan operation. For larger result sets, use pagination. When results exceed 1MB, DynamoDB returns LastEvaluatedKey: use this as ExclusiveStartKey in your next request to continue where you left off. The Limit parameter controls how many items to evaluate per page, not how many to return: filtering happens after evaluation. Continue paginating until LastEvaluatedKey is null, indicating no more results. This pattern is essential for large tables and prevents memory issues in your application.

8. Let's practice!

Let's now practice what we have learned!

Create Your Free Account

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.