Amazon DynamoDB Single-Table Design Helper Tool - Key, Sort Key and GSI Designer

First Published: 2026-06-24
Last Updated: 2026-06-24

Design an Amazon DynamoDB single-table schema from your access patterns. Enter your entities and the queries your application needs, and this tool proposes partition keys, sort keys, and global secondary indexes as a starting point - entirely in your browser.

All processing is performed entirely in your browser using client-side JavaScript. No data is transmitted to any server, no AWS connection is made, and no cost or capacity is estimated. Your entities and access patterns never leave your device.

This tool is provided "AS IS" without any warranties of any kind.
There is no single correct DynamoDB design. The suggestions are a starting point (たたき台) that follow published best practices, not an authoritative schema.
Review every suggestion against your real access patterns, item sizes, and partition key distribution before building.
This tool does not connect to AWS, does not create tables, and does not estimate cost or capacity.
By using this tool, you accept full responsibility for any outcomes.

This tool uses client-side JavaScript for all processing. No data is transmitted to servers, no files are uploaded online, all processing happens locally in your browser. Once loaded, this tool continues to work even without an internet connection. For more details, please refer to our Web Tools Disclaimer.

Examples

Load a worked example to see how entities and access patterns map to keys and indexes.

1. Entities

List each entity type, its identifier attribute, and any other attributes you store.

2. Access Patterns

Describe each query your application needs. Choose an access type: Get one by ID (base table), List items belonging to a parent (item collection), Look up by another attribute (global secondary index), List all of this entity (overloaded / sparse index), or Other (manual modeling). The key attribute is the value used in the equality condition; the sort / range attribute is optional.

DynamoDB Key and Index Constraints (Reference)

Verified against the Amazon DynamoDB Developer Guide on 2026-06-23. Quotas marked default are adjustable via Service Quotas.

Concept / limit	Value	Source
Primary key	Partition key (required) plus an optional sort key (composite primary key)	Core components
Query operation	Partition key equality is required; the sort key supports `=`, `<`, `>`, `between`, `begins_with`	Query
Global secondary indexes (GSI)	Default 20 per table; different keys from the base table; own throughput; eventually consistent reads	Quotas
Local secondary indexes (LSI)	5 per table; same partition key, different sort key; created only at table creation; supports strong consistency	Secondary index guidelines
LSI item-collection size	Total indexed items per partition key value cannot exceed 10 GB	Secondary index guidelines
Projected attributes	Up to 100 user-specified attributes combined across all secondary indexes (INCLUDE projection)	Quotas
Maximum item size	400 KB (compress, vertically partition, or offload large blobs to Amazon S3)	Large items
Key attribute length	Partition key up to 2048 bytes; sort key up to 1024 bytes	Constraints
GSI overloading	One generic attribute (e.g. `GSI1PK`) can serve many entity types, letting you index far more than 20 fields	GSI overloading
Sparse index	Items missing the index key attribute are excluded, so a sparse index efficiently returns a small subset	Sparse indexes

About This Tool

Single-table design is a DynamoDB pattern that stores multiple entity types (for example users, orders, and products) in one table. Items that share a partition key form an item collection stored together on the same partition(s), and the sort key differentiates entity types and gathers related records for efficient range queries. Because DynamoDB requires you to know your access patterns before you design the schema, this tool starts from the queries your application needs and works backward to the keys and indexes that satisfy them.

You enter your entities and access patterns, and the tool applies a transparent heuristic: lookups by a unique ID resolve to the base table, parent-to-child listings become item collections under a shared partition key, and lookups by other attributes are routed onto overloaded global secondary indexes (GSI1PK / GSI1SK, GSI2PK / GSI2SK, and so on). It then produces a key schema, a per-pattern coverage table, illustrative item shapes, sample item JSON, and a CreateTable skeleton you can copy.

The DynamoDB constraints used by this tool (the 20-GSI and 5-LSI defaults, the 400 KB item-size limit, and key-length limits) were verified against the Amazon DynamoDB Developer Guide on 2026-06-23. These quotas and behaviors can change over time, and the listed defaults are adjustable through Service Quotas. The output is a proposal, not the one correct design - real projects balance access patterns, item sizes, write amplification, and partition distribution in ways no heuristic can fully capture. For RCU/WCU and cost planning, use the companion DynamoDB Capacity Calculator Tool.

Features

Access-Pattern-First: Start from the queries your application needs and let the tool derive partition keys, sort keys, and indexes - the recommended DynamoDB modeling order.
Composite Key Naming: Generates generic composite keys (USER#<userId>, ORDER#<orderId>) and item-collection layouts for parent-to-child relationships.
Overloaded GSI Proposals: Routes alternate-attribute lookups onto reusable GSI1PK / GSI1SK style indexes, the standard single-table technique for indexing many fields.
Coverage Table: Maps every access pattern to the table or GSI, the operation (GetItem / Query), and the exact key condition, flagging any pattern that needs manual modeling.
Item Shapes and Sample JSON: Shows the PK/SK and GSI attributes each entity carries, with copyable sample items.
CreateTable Skeleton: Emits an AttributeDefinitions / KeySchema / GlobalSecondaryIndexes skeleton for the AWS CLI or SDK.
Worked Examples: One-click Users and Orders, Blog Posts and Comments, and Multi-tenant SaaS scenarios.
Constraints Reference: A built-in, source-linked table of DynamoDB key and index limits verified against the official Developer Guide.
Privacy First: 100% client-side. No AWS connection, no data leaves the browser, and no cost is estimated.

How to Use

Click an Example (Users and Orders, Blog Posts and Comments, or Multi-tenant SaaS) to see a worked design, or start from scratch.
In Entities, add each entity type with its ID attribute and any other attributes.
In Access Patterns, describe each query, pick the target entity and the access type, and enter the key attribute (and an optional sort / range attribute).
Click Generate Design.
Review the Keys and Patterns tab for the key schema and the per-pattern coverage table.
Check Item Shapes for per-entity layouts and sample items, and CreateTable for the table skeleton.
Use Copy Markdown, Copy CreateTable JSON, or Copy Sample Items JSON to paste into a design doc, ticket, or your IaC repository.

FAQ

Q1. What is single-table design in DynamoDB?
It is a pattern that stores multiple entity types in one DynamoDB table. Items with the same partition key form an item collection on the same partition(s), and the sort key differentiates entity types. It optimizes for data locality and fewer tables to manage, at the cost of a steeper learning curve and all-or-nothing backups, encryption, and Streams granularity. It is not mandatory - multiple-table design is a valid choice when entities have independent access patterns and operational needs.

Q2. What is the difference between a partition key (PK) and a sort key (SK)?
The partition key determines which physical partition stores an item and must be provided as an equality condition on every Query. The sort key orders items within a partition and supports range conditions such as begins_with, between, <, and >. Together they form a composite primary key that uniquely identifies an item. Well-designed composite sort keys (for example country#region#city) let you query at any level of a hierarchy.

Q3. When do I need a global secondary index (GSI)?
When you need to query by an attribute that is not the table's partition key - for example "find a user by email" when the table is keyed by user ID. A GSI defines an alternate partition/sort key. In single-table design you typically overload a few generic GSIs (GSI1PK / GSI1SK) across many entity types rather than creating one index per query.

Q4. What is the difference between a GSI and an LSI?
A global secondary index can use any attributes as its keys, has its own throughput, supports only eventually consistent reads, and can be added at any time (default quota 20 per table). A local secondary index shares the base table's partition key, supports strongly consistent reads, shares the table's throughput, must be created when the table is created, and is limited to 5 per table with a 10 GB item-collection size limit. GSIs are generally more flexible.

Q5. Is the output the correct design for my application?
No. It is a starting point that follows published best practices. There is no single correct DynamoDB design - the right schema depends on your real access patterns, item sizes, read/write ratios, and partition distribution. Treat the output as a draft to review and refine, and use the linked capacity calculator and design articles to go deeper.

Important Notes

This helper proposes single-table key and index designs as a starting point, following DynamoDB best practices as of 2026-06-23. There is no single correct design - review the suggestions against your real access patterns, item sizes, and partition distribution. This tool does not connect to AWS and does not estimate cost or capacity.
The heuristic assigns one overloaded GSI per distinct alternate lookup per entity. In practice you can often consolidate further with GSI overloading, or you may need additional indexes the heuristic does not propose. Always sanity-check the GSI count against the default quota of 20 per table.
A constant partition value (used for "list all of this entity") concentrates writes on one partition. For high-volume entity types, apply write sharding or a different grouping attribute to avoid a hot partition.
Keep items under the 400 KB limit. For large attributes, compress them, split them across sort-key items, or store the blob in Amazon S3 and keep only a pointer in DynamoDB.
The CreateTable skeleton uses Projection ALL and on-demand billing for simplicity. Choose projections deliberately - projecting fewer attributes lowers index storage and write cost; projecting ALL avoids table fetches but roughly doubles storage and write cost.
For RCU/WCU sizing and cost comparisons, use the DynamoDB Capacity Calculator Tool. This design tool intentionally does not estimate capacity or cost.

Related Tools

References:
Tech Blog with curated related content
Web Tools Collection

Written by Hidekazu Konishi

hidekazu-konishi.com