The 7 DynamoDB Sins - by Uriel Bitton

I discuss more about primary key design and how to implement it in this article. Remember, if you’re not carefully designing your primary keys like this, using DynamoDB will do you more harm than good. **2. Querying Without Projection Expressions (Greed)** The second DynamoDB sin. You’re probably missing this one from your skillset. … You get back nothing more and nothing less. Want to learn how projection expressions work? Find out more here. **3. Abusing Scans Instead Of Queries (Lust)** The third DynamoDB sin. The Scan method lets you have unbounded querying and filtering capabilities. However, most of the time you don’t want to use it. … **Normalizing data**: Data in DynamoDB should be denormalized for the most part. Relationships between data should be stored on the same table. There are no joins in Dynamo so all queries should be self-contained **Misunderstanding Primary Key design**: Primary key design is drastically different in Dynamo than SQL. Primary keys should be designed for specific data access patterns and are responsible for scalability and performance, unlike SQL. **Using Filters instead of Indexing:**Using FilterExpressions has a caveat — when filtering to narrow down results, DynamoDB first retrieves matching items and then applies the filter afterward. Instead of filters, you should be relying on secondary indexes for filtering data. **Ignoring DynamoDB’s Event-Driven nature:**You shouldn’t be using DynamoDB as a static database like in SQL, make use of Streams to react to events. This makes your data more Dynamic by enabling event-driven capabilities. **Overusing Multi-item transactions:**While DynamoDB can support transactions, it isn’t ideal for complex multi-item transactions like in SQL. Instead, learn to model your data to avoid requiring complex transactions. There are many more but those are the anti-patterns most seen in my experience. **5. Over-Provisioning Read/Write Capacity (Gluttony)** The 5th DynamoDB sin. Many DynamoDB users are guilty of this one. There are two issues here: When to use On-demand vs Provisioned Capacity mode. … avoid large arrays or nested objects use sparse indexes where only items with specific attributes are included Additionally, being aware of DynamoDB’s other limitations is very important. query/scan limits of 1MBs of data partition throughput limits secondary indexes limits eventual consistency limits on transaction/batches streams retention