AWS DynamoDB Skill DynamoDB is a fully managed NoSQL database designed for single digit millisecond performance at any scale. Master single table design and access pattern modeling. Sources: [DynamoDB Docs](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/) [SDK v3](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/dynamodb/) [Best Practices](https://aws.amazon.com/blogs/database/single table vs multi table design in amazon dynamodb/) Core Principle Design for access patterns, not entities. Think access pattern first. DynamoDB requires you to know your queries before designing your schema. Model around how you'll access data, not how data relates. Single table design stores multiple entity types in one table using generic key attributes. Key Concepts Concept Description Partition Key (PK) Primary key attribute determines data distribution Sort Key (SK) Optional secondary key for range queries within partition GSI Global Secondary Index alternate partition/sort keys LSI Local Secondary Index same partition, different sort Item Single record (max 400 KB) Attribute Field within an item Single Table Design Why Single Table? Fetch related data in single query Reduce round trips and costs Enable transactions across entity types Simplify operations (backup, restore, IAM) Generic Key Pattern Example: E commerce Schema Access Patterns Covered SDK v3 Setup (TypeScript) Install Dependencies Client Configuration Type Definitions CRUD Operations Put Item (Create/Update) Get Item (Read) Query (List/Search) Update Item Delete Item Batch Operations Batch Write (Up to 25 items) Batch Get (Up to 100 items) Transactions TransactWrite (Atomic Multi Item) GSI Patterns Sparse Index Inverted Index (GSI) Multi Attribute Composite Keys (Nov 2025+) Python (boto3) Setup Operations Local Development DynamoDB Local NoSQL Workbench AWS provides [NoSQL Workbench](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/workbench.html) for visual data modeling and querying. CLI Quick Reference Anti Patterns Scan operations Always use Query with proper key conditions Hot partitions Distribute writes with high cardinality partition keys Large items Keep items under 400KB; use S3 for large data Too many GSIs Each GSI duplicates data; design carefully Ignoring capacity Monitor consumed capacity, use on demand for variable loads No condition expressions Always validate with ConditionExpression Fetching all attributes Use ProjectionExpression to limit data Multi table design without reason Single table is preferred unless access patterns don't overlap

aws-dynamodb