AWS Database Services

Amazon DynamoDB

6 min read
Updated June 21, 2025
6,459 characters

Core Components

  • Tables: A collection of data. Unlike a relational database, a DynamoDB table is schemaless.
  • Items: A single data record in a table. Each item is a collection of attributes. This is analogous to a row or record in a traditional database.
  • Attributes: A fundamental data element of an item, similar to a column in a relational database. Each attribute has a name and a value.

Primary Keys

The primary key uniquely identifies each item in a table. It can be one of two types:

  • Partition Key (Simple Primary Key):

    • A single attribute.
    • DynamoDB uses the partition key's value as input to an internal hash function. The output from the hash function determines the partition (physical storage) in which the item will be stored.
    • No two items can have the same partition key.
  • Composite Primary Key:

    • Composed of two attributes: a Partition Key and a Sort Key.
    • All items with the same partition key are stored together, ordered by the sort key value.
    • This allows you to query for all items with a specific partition key and then further refine the results using the sort key (e.g., get all users from 'USA' and sort them by 'registration_date').

Secondary Indexes

Indexes allow for efficient querying of attributes other than the primary key.

Local Secondary Index (LSI)

  • An index that has the same partition key as the base table but a different sort key.
  • You can only create LSIs when you create the table. You cannot add them later.
  • The index is "local" because every partition of an LSI is scoped to a base table partition that has the same partition key value.
  • Queries on an LSI can be either strongly consistent or eventually consistent.

Global Secondary Index (GSI)

  • An index with a partition key and sort key that can be different from those on the base table.
  • You can create GSIs on an existing table.
  • The index is "global" because queries on the index can span all of the data in the base table, across all partitions.
  • GSI queries only support eventually consistent reads.

LSI vs. GSI Comparison

Feature Local Secondary Index (LSI) Global Secondary Index (GSI)
Primary Key Same Partition Key, different Sort Key Can have different Partition & Sort Keys
Creation Time Can only be created at table creation Can be created at any time
Read Consistency Supports Strongly & Eventually Consistent Only supports Eventually Consistent
Provisioned Throughput Shares throughput with the base table Has its own separate provisioned throughput
Item Collection Size Limited to 10 GB per partition key value No size limit

Read/Write Capacity Modes

  • Provisioned Throughput:

    • You specify the number of reads and writes per second you require for your application.
    • Read Capacity Unit (RCU): One strongly consistent read per second, or two eventually consistent reads per second, for an item up to 4 KB in size.
    • Write Capacity Unit (WCU): One write per second for an item up to 1 KB in size.
    • Adaptive Capacity: A feature that automatically boosts throughput to "hot" partitions to mitigate throttling, without you needing to manage it manually.
  • On-Demand:

    • DynamoDB instantly accommodates your application's workload as it ramps up or down.
    • You pay per request for the data reads and writes your application performs on your tables.
    • Ideal for applications with unpredictable traffic patterns.

Read Consistency Models

  • Eventually Consistent Reads (Default):

    • Maximizes read throughput. When you read data, the response might not reflect the results of a recently completed write. The data is usually consistent within a second.
    • Consumes 0.5 RCU for items up to 4 KB.
  • Strongly Consistent Reads:

    • A strongly consistent read returns a result that reflects all writes that received a successful response prior to the read.
    • Consumes 1 RCU for items up to 4 KB.

Key Features & Services

  • DynamoDB Accelerator (DAX):

    • A fully managed, in-memory cache for DynamoDB.
    • Delivers up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second.
    • It's API-compatible with DynamoDB, so you don't need to rewrite your application logic.
  • DynamoDB Streams:

    • Provides a time-ordered sequence of item-level modifications (inserts, updates, deletes) in a DynamoDB table.
    • This change data capture (CDC) stream can be used to trigger AWS Lambda functions, enabling event-driven architectures, real-time analytics, and cross-region replication.
  • Time To Live (TTL):

    • Allows you to define a per-item timestamp to determine when an item is no longer needed.
    • DynamoDB automatically deletes expired items from your tables at no extra cost, which is useful for managing session data, logs, and other transient information.
  • Global Tables:

    • Provides a fully managed, multi-region, multi-active database solution.
    • You can define DynamoDB tables that are automatically replicated across your choice of AWS Regions, enabling low-latency data access for globally distributed applications.

API Actions

  • Control Plane: Operations for managing tables (e.g., CreateTable, UpdateTable, DeleteTable, DescribeTable).
  • Data Plane: Operations for working with data (items) within a table.
    • CRUD: PutItem (create/update), GetItem (read), UpdateItem, DeleteItem.
    • Batch: BatchGetItem, BatchWriteItem.
    • Query: Finds items based on the primary key. Highly efficient. You must specify the partition key.
    • Scan: Reads every item in a table or secondary index. It is less efficient than a query and can consume a lot of provisioned throughput.

NoSQL Design Principles

  • Unlike relational databases where you design a normalized schema first, DynamoDB design should be driven by access patterns.
  • Understand the business problems and application use cases first. Design your schema to make the most common and important queries as fast and inexpensive as possible.
  • Well-designed applications often require only one table.
    Sources