Amazon DynamoDB Table Design Patterns - Single-Table Design and GSI Strategies
Learn about DynamoDB partition key design, single-table design, and how to implement diverse access patterns using GSIs.
Overview of DynamoDB
DynamoDB is a fully managed NoSQL database that delivers single-digit millisecond latency. Unlike RDS, it is schemaless and accesses data through a combination of partition keys and sort keys. In serverless architectures, it can be used alongside Lambda and API Gateway. It offers two capacity modes: on-demand and provisioned. DynamoDB automatically scales on a per-partition basis, with each partition handling up to 10 GB of data and 3,000 RCU / 1,000 WCU per second. There is no upper limit on table size.
Table Design
The partition key directly affects data distribution, so choose attributes with high cardinality (such as user IDs or order IDs). In single-table design, the PK is prefixed like "USER#123" or "ORDER#456", and the SK represents entity types and relationships. A Query specifying the PK can retrieve both user information and order history in a single call. GSIs support different access patterns (e.g., looking up users by email address or searching orders by date range), and you can create up to 20 per table. Choosing low-cardinality values like dates or status codes for partition keys sometimes concentrates access on specific partitions, creating hot partitions. In such cases, append a suffix (random value or partial timestamp) to the key to distribute requests.
GSI and Single-Table Design
Global Secondary Indexes (GSIs) allow queries using a different partition key and sort key from the main table. In single-table design, multiple entities (users, orders, products) are stored in a single table, and GSI overloading handles diverse access patterns. Prefixes like 'USER#123' for PK and 'ORDER#456' for SK are used, and entities are filtered with the begins_with condition. Sparse indexes include only items with specific attributes in the index, which keeps index size and cost down.
Design Best Practices and Pitfalls
Single-table design is not suitable for all cases. For applications with complex inter-entity relationships and frequently changing access patterns, separating tables may be easier to operate. GSI write throttling propagates to the main table, so design GSI capacity to keep up with the main table's write volume. With BatchWriteItem, sometimes part of the writes succeeds while the rest is not processed, so the application retries unprocessed items. In event-driven patterns combining DynamoDB Streams with Lambda, the number of parallel Lambda executions depends on the number of partitions. Adaptive Capacity automatically raises throughput for hot partitions, but cannot exceed the total provisioned capacity for the table.
When to Use DynamoDB vs. RDS
DynamoDB specializes in key-based reads and writes, handling simple key lookups and range queries with low latency. For complex JOIN queries, aggregations, and workloads centered on ACID transactions, one approach is to use RDS (Aurora / PostgreSQL). DynamoDB transactions (TransactWriteItems / TransactGetItems) have a limit of 100 items and can group items from multiple tables within the same AWS account and the same Region. DynamoDB is used for purposes such as user profiles, session stores, real-time leaderboards, and IoT device data ingestion. For workloads primarily consisting of reporting and analytical queries, one approach is to export from DynamoDB to S3 and analyze with Athena, or sync to OpenSearch via DynamoDB Streams.
DynamoDB Cost Optimization
DynamoDB's on-demand mode charges based on the number of read (RRU) and write (WRU) requests. Provisioned mode charges hourly for WCU/RCU, and for stable workloads, combining it with Auto Scaling lets capacity follow the load. Reserved capacity offers discounts. Since GSIs consume their own capacity, removing unnecessary GSIs and narrowing projection attributes keeps storage costs down. Use TTL to automatically delete expired data and keep storage costs down.
Summary
DynamoDB is a NoSQL database that accesses data through partition key and sort key design. GSI overloading and single-table design support diverse access patterns, while sparse indexes keep index costs down. By choosing between on-demand and provisioned modes and using TTL for automatic data deletion, you can manage costs.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- Amazon DynamoDB official page
- Amazon DynamoDB Accelerator official page
- AWS Lambda official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.