Creating and Managing DynamoDB Tables

Introduction

Everything in DynamoDB starts with a table. Unlike relational databases, you do not create schemas, columns, foreign keys, or relationships up front. You create a table with a primary key, choose the right configuration, and then store items that can have different attributes.

This flexibility is one reason DynamoDB scales well, but table creation is still an architectural decision. A production table needs the right primary key, capacity mode, encryption, backups, lifecycle settings, and operational guardrails.

Purpose of this lesson

By the end of this lesson, you will be able to create DynamoDB tables using the AWS Console, AWS CLI, Java SDK, Python Boto3, and Node.js SDK. You will also understand table configuration options such as primary keys, capacity modes, encryption, PITR, streams, TTL, tags, and table lifecycle states.

Understanding the topic

A DynamoDB table is a collection of related items. Each table stores a specific category of application data, such as customers, orders, products, accounts, transactions, restaurants, or users.

Internal architecture

A production DynamoDB table is more than a name and primary key. It sits behind application APIs and should include security, recovery, lifecycle, and observability decisions from the beginning.

Visual explanation

Every table moves through lifecycle states. Applications should wait until a table reaches ACTIVE before sending reads or writes.

Step-by-step explanation

1. Choose a meaningful table name that represents the business entity or access pattern.
2. Select the primary key based on how the application reads data.
3. Choose On-Demand or Provisioned Capacity based on traffic predictability.
4. Enable encryption for production data.
5. Enable Point-in-Time Recovery for accidental deletion and disaster recovery.
6. Optionally enable Streams for event-driven processing.
7. Optionally enable TTL for temporary or expiring data.
8. Add tags for ownership, cost allocation, and operations.

Production implementation

You can create a DynamoDB table through the AWS Console, AWS CLI, or SDKs. In all cases, the key choices are the same: table name, primary key, capacity mode, and production features such as encryption and PITR.

Create table examples

aws dynamodb create-table \
  --table-name Customers \
  --attribute-definitions AttributeName=CustomerId,AttributeType=S \
  --key-schema AttributeName=CustomerId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

DynamoDbClient client = DynamoDbClient.create();

CreateTableRequest request = CreateTableRequest.builder()
    .tableName("Customers")
    .billingMode(BillingMode.PAY_PER_REQUEST)
    .attributeDefinitions(
        AttributeDefinition.builder()
            .attributeName("CustomerId")
            .attributeType(ScalarAttributeType.S)
            .build())
    .keySchema(
        KeySchemaElement.builder()
            .attributeName("CustomerId")
            .keyType(KeyType.HASH)
            .build())
    .build();

client.createTable(request);

import boto3

dynamodb = boto3.client("dynamodb")

dynamodb.create_table(
    TableName="Customers",
    KeySchema=[
        {
            "AttributeName": "CustomerId",
            "KeyType": "HASH"
        }
    ],
    AttributeDefinitions=[
        {
            "AttributeName": "CustomerId",
            "AttributeType": "S"
        }
    ],
    BillingMode="PAY_PER_REQUEST"
)

import {
  DynamoDBClient,
  CreateTableCommand
} from "@aws-sdk/client-dynamodb";

const client = new DynamoDBClient({});

await client.send(new CreateTableCommand({
  TableName: "Customers",
  BillingMode: "PAY_PER_REQUEST",
  AttributeDefinitions: [
    {
      AttributeName: "CustomerId",
      AttributeType: "S"
    }
  ],
  KeySchema: [
    {
      AttributeName: "CustomerId",
      KeyType: "HASH"
    }
  ]
}));

Real-world use

Suppose you are building a food delivery platform. You might start with Customers, Restaurants, Orders, and Drivers. For each table, start with On-Demand Capacity, enable encryption, enable PITR, define meaningful primary keys, and monitor CloudWatch metrics.

• Customers: partition key CustomerId.
• Restaurants: partition key RestaurantId.
• Orders: composite key such as CustomerId + OrderDate if the main access pattern is order history by customer.
• Drivers: partition key DriverId, with TTL or location update strategy depending on the design.

Security implications

Every production table should be encrypted and protected by least-privilege IAM permissions. DynamoDB supports AWS owned keys, AWS managed KMS keys, and customer managed KMS keys.

• AWS owned key: easiest default, fully managed by AWS.
• AWS managed KMS key: AWS managed key in your account.
• Customer managed KMS key: use when compliance requires key ownership, rotation control, or audit policies.
• IAM: grant applications only the table actions they need, such as dynamodb:GetItem, dynamodb:PutItem, or dynamodb:Query.

Failure scenarios

Point-in-Time Recovery protects against accidental writes and deletes. If someone deletes a million customer records, PITR lets you restore the table to any second within the last 35 days.

• Restore after accidental deletion or bad deployment.
• Recover from application bugs that overwrite data.
• Support operational rollback without manual backup jobs.
• Recommended for production tables by default.

Decision framework

• Choose table names that represent business concepts or access patterns.
• Choose primary keys based on how the application reads data.
• Use On-Demand Capacity for new or unpredictable workloads.
• Use Provisioned Capacity when traffic is stable and you need cost control.
• Enable PITR for production tables.
• Enable TTL for data that naturally expires, such as OTPs, sessions, temporary tokens, carts, and reservations.
• Use Streams when item changes should trigger Lambda functions, audit flows, notifications, or event-driven pipelines.

Best practices

• Design tables around access patterns.
• Prefer single-table design for complex applications when appropriate.
• Choose high-cardinality partition keys.
• Enable PITR for production tables.
• Keep encryption enabled.
• Use meaningful table names.
• Enable CloudWatch monitoring and alarms.
• Use tags for cost allocation and ownership.
• Avoid unnecessary tables before understanding query patterns.

Common mistakes

• Creating many small tables unnecessarily.
• Choosing poor partition keys.
• Forgetting to enable PITR.
• Ignoring IAM permissions.
• Disabling or overlooking encryption.
• Using Provisioned Capacity without traffic analysis.
• Creating tables before understanding application queries.

Advanced interview questions

Hands-on exercise

Build a DynamoDB table design for an Online Library Management System. The table should support book information and temporary reservations.

• Choose an appropriate table name.
• Select the primary key.
• Decide between On-Demand and Provisioned Capacity.
• Explain why PITR is important for this application.
• Describe how TTL could automatically expire book reservations.

Summary

In this lesson, you learned how to create and manage DynamoDB tables using the AWS Console, AWS CLI, Java SDK, Python Boto3, and Node.js SDK. You also learned the production meaning of table options such as primary keys, capacity modes, encryption, Point-in-Time Recovery, Streams, TTL, tags, IAM, CloudWatch, and table lifecycle states.

A well-configured table is the foundation of a secure, scalable, and maintainable DynamoDB application. Table creation should not be treated as a quick setup step; it is where access patterns, security, reliability, recovery, and cost decisions begin.

Next: Lesson 6 covers working with items: PutItem, GetItem, UpdateItem, DeleteItem, conditional writes, batch operations, error handling, optimistic locking, SDK examples, production best practices, and interview questions.