Uriel Bitton
@urielbitton.bsky.social
AWS Cloud Consultant | The DynamoDB guy | AWS Certified | I help you design cost-effective DynamoDB databases ☁️
💡 Learn from these mistakes that i've made in the past, they will give you an unfair advantage !
What common DynamoDB mistakes did I miss?
Comment them below 👇
What common DynamoDB mistakes did I miss?
Comment them below 👇
September 9, 2025 at 12:11 PM
💡 Learn from these mistakes that i've made in the past, they will give you an unfair advantage !
What common DynamoDB mistakes did I miss?
Comment them below 👇
What common DynamoDB mistakes did I miss?
Comment them below 👇
Instead adding a TTL to these temporary items will let DynamoDB delete them automatically without costing you anything even at scale.
September 9, 2025 at 12:11 PM
Instead adding a TTL to these temporary items will let DynamoDB delete them automatically without costing you anything even at scale.
3️⃣ Not adding TTLs to expirable data
Data that will expire such as connection IDs, session data, or any data that won't be relevant after some time should have a TTL.
That data will accumulate and it will add up to your storage, deleting it manually will cost you a lot at scale.
Data that will expire such as connection IDs, session data, or any data that won't be relevant after some time should have a TTL.
That data will accumulate and it will add up to your storage, deleting it manually will cost you a lot at scale.
September 9, 2025 at 12:11 PM
3️⃣ Not adding TTLs to expirable data
Data that will expire such as connection IDs, session data, or any data that won't be relevant after some time should have a TTL.
That data will accumulate and it will add up to your storage, deleting it manually will cost you a lot at scale.
Data that will expire such as connection IDs, session data, or any data that won't be relevant after some time should have a TTL.
That data will accumulate and it will add up to your storage, deleting it manually will cost you a lot at scale.
2️⃣ Fetching data to increment a value
Don't use a get item to increment an attribute's value or add to an array.
DynamoDB offers methods like ADD and list_append to increment values and push to arrays without fetching the item before.
Don't use a get item to increment an attribute's value or add to an array.
DynamoDB offers methods like ADD and list_append to increment values and push to arrays without fetching the item before.
September 9, 2025 at 12:11 PM
2️⃣ Fetching data to increment a value
Don't use a get item to increment an attribute's value or add to an array.
DynamoDB offers methods like ADD and list_append to increment values and push to arrays without fetching the item before.
Don't use a get item to increment an attribute's value or add to an array.
DynamoDB offers methods like ADD and list_append to increment values and push to arrays without fetching the item before.
1️⃣ Filtering data with Filter Expressions
If your go-to approach for filtering data is using filter expressions, your costs will be higher and queries slower.
Filter expressions should be a last resort; instead filter with your sort key by adding multiple values in it and separating them with "#".
If your go-to approach for filtering data is using filter expressions, your costs will be higher and queries slower.
Filter expressions should be a last resort; instead filter with your sort key by adding multiple values in it and separating them with "#".
September 9, 2025 at 12:11 PM
1️⃣ Filtering data with Filter Expressions
If your go-to approach for filtering data is using filter expressions, your costs will be higher and queries slower.
Filter expressions should be a last resort; instead filter with your sort key by adding multiple values in it and separating them with "#".
If your go-to approach for filtering data is using filter expressions, your costs will be higher and queries slower.
Filter expressions should be a last resort; instead filter with your sort key by adding multiple values in it and separating them with "#".
Most apps i've built have used at least these services.
You also benefit from the efficency, cost-effectiveness and power of serverless.
Learn just the basics to build early, then move up from there to expand your skillset.
You also benefit from the efficency, cost-effectiveness and power of serverless.
Learn just the basics to build early, then move up from there to expand your skillset.
August 27, 2025 at 12:37 PM
Most apps i've built have used at least these services.
You also benefit from the efficency, cost-effectiveness and power of serverless.
Learn just the basics to build early, then move up from there to expand your skillset.
You also benefit from the efficency, cost-effectiveness and power of serverless.
Learn just the basics to build early, then move up from there to expand your skillset.
Since DynamoDB stores items sorted by the sort key, you can:
✅ Fetch the latest item(s) with ScanIndexForward: false
✅ Query a granular range of items with begins_with() or BETWEEN methods
💡 The sort key lets you model advanced patterns like one-to-many relationships, hierarchical models, and more
✅ Fetch the latest item(s) with ScanIndexForward: false
✅ Query a granular range of items with begins_with() or BETWEEN methods
💡 The sort key lets you model advanced patterns like one-to-many relationships, hierarchical models, and more
July 9, 2025 at 1:45 PM
Since DynamoDB stores items sorted by the sort key, you can:
✅ Fetch the latest item(s) with ScanIndexForward: false
✅ Query a granular range of items with begins_with() or BETWEEN methods
💡 The sort key lets you model advanced patterns like one-to-many relationships, hierarchical models, and more
✅ Fetch the latest item(s) with ScanIndexForward: false
✅ Query a granular range of items with begins_with() or BETWEEN methods
💡 The sort key lets you model advanced patterns like one-to-many relationships, hierarchical models, and more
Examples: For a userID partition key, the sort key can be:
✔️ order#123, order#124 (to store a user's purchases)
✔️ post#101, post#102 (to store a user's blog posts)
✔️ message#001, message#002 (to store a user's chat messages)
✔️ order#123, order#124 (to store a user's purchases)
✔️ post#101, post#102 (to store a user's blog posts)
✔️ message#001, message#002 (to store a user's chat messages)
July 9, 2025 at 1:45 PM
Examples: For a userID partition key, the sort key can be:
✔️ order#123, order#124 (to store a user's purchases)
✔️ post#101, post#102 (to store a user's blog posts)
✔️ message#001, message#002 (to store a user's chat messages)
✔️ order#123, order#124 (to store a user's purchases)
✔️ post#101, post#102 (to store a user's blog posts)
✔️ message#001, message#002 (to store a user's chat messages)
While the partition key decides where data is stored, the sort key controls how it's organized inside that partition.
💡 Sort keys let you store multiple related items under the same partition key (aka an item collection) which lets you efficiently query these items in order.
💡 Sort keys let you store multiple related items under the same partition key (aka an item collection) which lets you efficiently query these items in order.
July 9, 2025 at 1:45 PM
While the partition key decides where data is stored, the sort key controls how it's organized inside that partition.
💡 Sort keys let you store multiple related items under the same partition key (aka an item collection) which lets you efficiently query these items in order.
💡 Sort keys let you store multiple related items under the same partition key (aka an item collection) which lets you efficiently query these items in order.
When you design your partition keys smartly, your table can scale infinitely.
July 8, 2025 at 12:14 PM
When you design your partition keys smartly, your table can scale infinitely.
💡Some partition key design tips:
✅ Use unique IDs like UUID for userId, orderId, postId, etc
✅ Use item collection suffixes for related data: e.g. u#1234#posts, u#1234#orders, etc.
✅ Shard partition keys that get a lot of traffic: e.g. user#1234#shard1, user#1234#shard2, etc.
✅ Use unique IDs like UUID for userId, orderId, postId, etc
✅ Use item collection suffixes for related data: e.g. u#1234#posts, u#1234#orders, etc.
✅ Shard partition keys that get a lot of traffic: e.g. user#1234#shard1, user#1234#shard2, etc.
July 8, 2025 at 12:14 PM
💡Some partition key design tips:
✅ Use unique IDs like UUID for userId, orderId, postId, etc
✅ Use item collection suffixes for related data: e.g. u#1234#posts, u#1234#orders, etc.
✅ Shard partition keys that get a lot of traffic: e.g. user#1234#shard1, user#1234#shard2, etc.
✅ Use unique IDs like UUID for userId, orderId, postId, etc
✅ Use item collection suffixes for related data: e.g. u#1234#posts, u#1234#orders, etc.
✅ Shard partition keys that get a lot of traffic: e.g. user#1234#shard1, user#1234#shard2, etc.
E.g. If thousands of users all access your app at once, don't use userId = "admin" as your partition key. That'll throttle queries.
July 8, 2025 at 12:14 PM
E.g. If thousands of users all access your app at once, don't use userId = "admin" as your partition key. That'll throttle queries.
But why does this matter?
👉 Choosing a high cardinality (unique value) partition key will distribute the load evenly.
👉 Choosing a hot key (too common) creates bottlenecks and uneven capacity usage.
👉 Choosing a high cardinality (unique value) partition key will distribute the load evenly.
👉 Choosing a hot key (too common) creates bottlenecks and uneven capacity usage.
July 8, 2025 at 12:14 PM
But why does this matter?
👉 Choosing a high cardinality (unique value) partition key will distribute the load evenly.
👉 Choosing a hot key (too common) creates bottlenecks and uneven capacity usage.
👉 Choosing a high cardinality (unique value) partition key will distribute the load evenly.
👉 Choosing a hot key (too common) creates bottlenecks and uneven capacity usage.
DynamoDB uses it to determine where to store the data internally.
💡 Think of it as a hashing function:
DynamoDB takes the value of the partition key, hashes it, and maps it to a partition in its storage system.
💡 Think of it as a hashing function:
DynamoDB takes the value of the partition key, hashes it, and maps it to a partition in its storage system.
July 8, 2025 at 12:14 PM
DynamoDB uses it to determine where to store the data internally.
💡 Think of it as a hashing function:
DynamoDB takes the value of the partition key, hashes it, and maps it to a partition in its storage system.
💡 Think of it as a hashing function:
DynamoDB takes the value of the partition key, hashes it, and maps it to a partition in its storage system.
DynamoDB requires very different thinking but it pays off
July 6, 2025 at 12:41 PM
DynamoDB requires very different thinking but it pays off
The takeaway here is not to model your data in DynamoDB as you traditionally would, but instead:
1. Understand your app's data access patterns
2. Model data based on these access patterns
3. Write queries to satisfy these specific access patterns
1. Understand your app's data access patterns
2. Model data based on these access patterns
3. Write queries to satisfy these specific access patterns
July 6, 2025 at 12:41 PM
The takeaway here is not to model your data in DynamoDB as you traditionally would, but instead:
1. Understand your app's data access patterns
2. Model data based on these access patterns
3. Write queries to satisfy these specific access patterns
1. Understand your app's data access patterns
2. Model data based on these access patterns
3. Write queries to satisfy these specific access patterns
Instead of focusing on normalizing data, you model your data based on access patterns.
This can feel unintuitive at first but it results in ultra low latency queries with predictable performance.
This can feel unintuitive at first but it results in ultra low latency queries with predictable performance.
July 6, 2025 at 12:41 PM
Instead of focusing on normalizing data, you model your data based on access patterns.
This can feel unintuitive at first but it results in ultra low latency queries with predictable performance.
This can feel unintuitive at first but it results in ultra low latency queries with predictable performance.
Relational databases are schema-first and optimized for complex queries and joins.
DynamoDB on the other hand is schema-less and designed for speed at scale.
DynamoDB on the other hand is schema-less and designed for speed at scale.
July 6, 2025 at 12:41 PM
Relational databases are schema-first and optimized for complex queries and joins.
DynamoDB on the other hand is schema-less and designed for speed at scale.
DynamoDB on the other hand is schema-less and designed for speed at scale.
Is your DynamoDB table costing you too much or not performing well?
I offer 15-minute consultations that can help you change this.
Message me now, and let's talk.
I offer 15-minute consultations that can help you change this.
Message me now, and let's talk.
June 30, 2025 at 1:56 PM
Is your DynamoDB table costing you too much or not performing well?
I offer 15-minute consultations that can help you change this.
Message me now, and let's talk.
I offer 15-minute consultations that can help you change this.
Message me now, and let's talk.
Lastly, the single table design, when applicable, can be a huge cost-saver.
If you have a lot of relational data, the single table design is a must use.
You can retrieve multiple items with a single query.
Learn how to design it if this is your case.
If you have a lot of relational data, the single table design is a must use.
You can retrieve multiple items with a single query.
Learn how to design it if this is your case.
June 30, 2025 at 1:56 PM
Lastly, the single table design, when applicable, can be a huge cost-saver.
If you have a lot of relational data, the single table design is a must use.
You can retrieve multiple items with a single query.
Learn how to design it if this is your case.
If you have a lot of relational data, the single table design is a must use.
You can retrieve multiple items with a single query.
Learn how to design it if this is your case.