AWS DynamoDB Explained: NoSQL Tables, Keys, and Access Patterns

Quick Answer

AWS DynamoDB is a fully managed cloud NoSQL database service that supports key-value and document data structures. It provides built-in security, continuous backups, automated multi-region replication, and integrated caching. To use DynamoDB effectively, you must define your access patterns before creating your tables, selecting a precise partition key and optional sort key to route requests efficiently across physical storage partitions without expensive table scans.

What Is DynamoDB?

DynamoDB operates as a distributed key-value and document store engineered for internet-scale applications. In a traditional relational database management system, data normalization and normalization rules dictate how tables link together using foreign keys, which often introduces performance bottlenecks when executing deep joins under heavy concurrent load. DynamoDB takes the opposite approach. It encourages denormalization, where related data items are grouped together into single tables or structured documents to ensure that retrieval operations touch as few storage partitions as possible.

Because DynamoDB is serverless, you do not manage database instances, cluster nodes, or operating systems. AWS manages underlying data replication across multiple Availability Zones automatically, ensuring high availability and durability by default. When an application sends a read or write request, the service instantly routes it to the appropriate storage node. This architecture makes DynamoDB an ideal backing store for high-frequency microservices, real-time analytics pipelines, gaming leaderboards, shopping cart sessions, and Internet of Things telemetry ingestion.

Tables and Items

Data organization in DynamoDB centers around three foundational pillars: tables, items, and attributes. A dynamodb table is a collection of data items, similar to a table in a relational database, but with a crucial distinction: it is schemaless. Aside from the primary key attributes required to identify an item, you do not need to pre-define column names, data types, or maximum lengths when you create a table.

Each row inside a table is called an item, and every item is composed of one or more attributes. Attributes are individual data elements like strings, numbers, binary data, boolean values, or nested maps and lists. Because the schema is flexible, two items in the exact same table can have entirely different attribute sets. For example, an order item might contain shipping details and tracking numbers, while a customer support ticket item in the same table contains priority flags and agent notes, without requiring sparse null columns across the storage engine.

Partition and Sort Keys

Primary keys

The primary key is the most critical architectural decision you make when designing a DynamoDB table. It uniquely identifies every item stored and dictates how data is distributed across physical storage partitions. DynamoDB supports two distinct primary key architectures: a simple primary key consisting solely of a partition key, and a composite primary key combining a partition key with a sort key.

A simple primary key uses only a partition key. The value of this attribute is fed into an internal hash function, and the resulting hash value determines the exact physical partition where the item is stored. When you perform a GetItem or DeleteItem operation, you must supply the exact partition key. In contrast, a composite primary key utilizes both a partition key and a sort key. The partition key groups related items onto the same physical partition, while the sort key organizes those items in sorted order on that partition. This model enables powerful range queries, allowing you to retrieve all items sharing the same partition key filtered by a range condition on the sort key.

Indexes

Indexes

While primary keys handle your core access paths, modern applications frequently require querying data using alternative attributes. Because DynamoDB does not support arbitrary ad-hoc SQL queries or multi-column joins, it uses secondary indexes to facilitate alternative query patterns. There are two types of secondary indexes available: Global Secondary Indexes (GSIs) and Local Secondary Indexes (LSIs).

A Global Secondary Index has a partition key and an optional sort key that can be completely different from those on the base table. Because a GSI is asynchronous and operates independently, it has its own provisioned throughput or on-demand capacity settings, and its data replication lag is measured in milliseconds. A Local Secondary Index, on the other hand, shares the same partition key as the base table but uses a different sort key. LSIs must be created at table creation time, share the base table's storage and throughput capacity, and enforce strong consistency options. In practice, Global Secondary Indexes are far more common because they offer architectural flexibility and can be added, modified, or deleted at any point after the base table is created.

Access-Pattern-First Design

Designing a database schema for DynamoDB requires an inverted mindset compared to relational modeling. In traditional database design, you model your entities first based on normalization rules, and then figure out how to query them later using SQL. In DynamoDB, you must identify all of your application's access patterns before you write a single line of infrastructure code.

You begin by listing every single read and write query your application will execute, such as finding a user by email, retrieving recent orders for a customer ID, or updating an item's status. Once these access patterns are documented, you design your dynamodb access patterns by mapping each query directly to primary keys, sort key prefixes, or secondary indexes. This ensures that every read operation is an efficient Query or GetItem request rather than an expensive, full-table Scan operation that consumes excessive read capacity units.

Capacity Concepts

Capacity

DynamoDB offers two distinct capacity modes to handle read and write throughput: Provisioned mode and On-Demand mode. In Provisioned mode, you specify the number of reads and writes per second your application requires. You can configure application Auto Scaling to automatically adjust provisioned capacity up or down based on actual traffic spikes. In On-Demand mode, DynamoDB instantly accommodates your workload as it ramps up or down, eliminating the need to manage capacity planning entirely.

Throughput is measured in Read Capacity Units (RCUs) and Write Capacity Units (WCUs). For writes, one WCU allows one write per second for an item up to 1 KB in size. For reads, one RCU allows one strongly consistent read per second, or two eventually consistent reads per second, for an item up to 4 KB in size. Strongly consistent reads return data reflecting all prior successful writes, whereas eventually consistent reads may return older data momentarily while replication completes across storage nodes.

Hot partitions

Understanding partition distribution is essential to maintaining stable application latency. A single physical partition in DynamoDB has strict throughput limits: typically up to 1,000 WCUs, 3,000 RCUs, and 10 GB of storage. When an application directs a disproportionate share of its read or write traffic to a single partition key, that specific partition becomes a hot partition.

When a partition overheats, requests targeting that partition may experience throttling errors, resulting in HTTP 400 status codes and increased latency. To prevent hot partitions, you must choose partition keys with high cardinality and even distribution. Avoid low-cardinality keys like status flags or boolean flags. Instead, use unique identifiers, composite keys with random hash prefixes, or user IDs that distribute traffic evenly across multiple underlying storage nodes.

Common Mistakes

Building high-performance applications with DynamoDB requires avoiding several common architectural pitfalls. The most frequent mistake is treating DynamoDB like a relational database by attempting ad-hoc scans. Executing a Scan operation reads every single item in the table and filters results in memory, which consumes massive amounts of read capacity and degrades performance rapidly as data volume grows. Always rely on targeted Query operations.

Another critical error involves neglecting partition key design, leading directly to hot partitions and throttling. Developers often pick static partition keys or low-cardinality attributes that concentrate traffic onto a single storage node. Additionally, using overly broad IAM permissions or embedding hardcoded access keys in source code creates severe security vulnerabilities. Always follow the principle of least privilege by scoping AWS IAM policies tightly to specific table resources and utilizing IAM roles or temporary security credentials for application access.