Challenge
One customer, tenant or status value takes most of the traffic, so one partition throttles.
Agnotic approach
Add a shard suffix or a more specific key, and test with the real distribution of busy keys.
Amazon DynamoDB
Amazon DynamoDB consulting and data modeling
DynamoDB is fast when the keys match how the application reads, and slow and costly when they do not. Agnotic Technologies designs DynamoDB tables from your access patterns, then tunes keys, indexes and capacity so reads stay predictable as traffic grows.
Access patterns firstKey and index designCapacity mode choiceStreams and TTL
Trusted by global innovators
DynamoDB consulting
What does Amazon DynamoDB consulting cover?
Amazon DynamoDB consulting is designing and tuning DynamoDB tables around the questions your application asks, not around entities. Agnotic Technologies lists every access pattern first, then chooses partition keys, sort keys, secondary indexes, capacity mode, Streams and TTL so each read is a key lookup or a query instead of a scan.
We work on new tables and on existing ones that throttle, cost more than expected or need a feature the current keys cannot serve.
If your workload needs ad hoc joins and reporting, we say so early. Analytics usually belongs in a warehouse such as Amazon Redshift, fed from DynamoDB.
Access pattern worksheet
Which keys serve each access pattern?
A short version of the worksheet we fill in with your team, here for an orders and support tickets model. Every row must map to a GetItem or a Query; a row that needs a Scan sends us back to the keys.
| Access pattern | Partition key | Sort key | Index | Query it supports |
|---|---|---|---|---|
| Get an order by ID | ORDER#<orderId> | METADATA | Base table | GetItem on the full primary key |
| List a customer's orders by date | CUSTOMER#<customerId> | ORDER#<orderDate>#<orderId> | Base table, orders stored under the customer | Query with begins_with on ORDER# and a date range |
| Open tickets by status, oldest first | STATUS#OPEN#<shard> | <createdAt> | Global secondary index on status and created time | Query each shard on the index and merge by date |
| All tickets for one order | ORDER#<orderId> | TICKET#<ticketId> | Base table, tickets stored with the order | Query with begins_with on TICKET# |
| Expire abandoned carts | CART#<sessionId> | CART | TTL attribute on the item | No query: DynamoDB deletes expired items |
The shard suffix on the status key spreads one busy value across several partitions, so a single status never becomes a hot key.
Design steps
How do we design a DynamoDB table?
The order matters. Keys chosen before the access patterns are known are the most common cause of a rebuild.
List the access patterns
Every read and write the application makes, with expected volume and the latency each one needs. This list drives every later choice.
Choose the partition key
A key with many distinct values that spreads traffic evenly, because each partition has its own throughput ceiling and one busy key can throttle.
Shape the sort key
Composite sort keys, such as a date plus an ID, let one Query return a filtered, ordered range instead of filtering after the read.
Add indexes for the remaining patterns
Global secondary indexes serve patterns that need a different key. Local secondary indexes share the partition key and are planned with the table itself.
Pick the capacity mode
On-demand is the AWS default and suits new or spiky traffic. Provisioned capacity with auto scaling suits steady, predictable load.
Load test with the real key spread
We replay realistic traffic, including your busiest customers or devices, and watch for throttling before launch.
Failure points
Why do DynamoDB tables throttle or cost too much?
The problems we find most often when we review a table that is already in production.
Challenge
The application uses Scan with filters for everyday reads.
Agnotic approach
Model each pattern as a Query on the table or an index, and keep Scan for exports and one-off jobs.
Challenge
A global secondary index falls behind on writes and slows the base table.
Agnotic approach
Give the index enough write capacity, or use on-demand, and project only the attributes its query needs.
Challenge
Items keep growing as lists are appended, so every read and write costs more.
Agnotic approach
Move growing lists into separate items under the same partition key and read them with a Query.
Challenge
The capacity mode was chosen at launch and never revisited.
Agnotic approach
Review usage after launch, and move between on-demand and provisioned as traffic becomes steady or spiky.
What do we build around DynamoDB?
The table is only part of the system. These are the pieces we design with it.
Single-table or multi-table design
One table when related items are read together and patterns are stable; separate tables when teams, retention rules or permissions differ. We write down why.
Change data with Streams
Stream consumers that update search indexes, publish events or feed a warehouse, written to handle retries and keep up with the stream's retention window.
TTL and data lifecycle
Expiry timestamps for sessions, carts and temporary records, with expired items archived through Streams when you need a copy.
Transactions where they matter
TransactWriteItems for all-or-nothing changes such as reserving stock and creating an order, kept small because transactional writes use more capacity.
Serverless APIs
AWS Lambda and Amazon API Gateway backends around DynamoDB, with IAM policies scoped to the tables and keys each function uses.
Security and recovery
Encryption with AWS KMS keys, point-in-time recovery, backups and IAM conditions on partition keys for multi-tenant data.
Fit check
When is DynamoDB the wrong choice?
We would rather tell you before the build than after it.
- Most queries are ad hoc, with filters and joins chosen by users at run time
- The team needs SQL reporting across many entities, which a relational database or a warehouse serves better
- Access patterns are still unknown and change every week during discovery
- Strict relational integrity across many tables is the core of the product
- Traffic is small and steady, and the team already runs PostgreSQL well
- In those cases we build on Amazon RDS or Aurora, or pair DynamoDB with a warehouse for analytics
Which workloads fit DynamoDB?
DynamoDB works best where the main reads are known lookups by a key.
Orders, carts and checkout
Lookups by order or customer at high volume, with transactions for the few steps that must succeed together.
User profiles and sessions
Fast reads by user ID, with TTL clearing old sessions on its own.
Device and event data
Readings keyed by device and time, queried as recent ranges for apps and alerts.
Multi-tenant SaaS metadata
Tenant-scoped keys with IAM conditions, so one tenant's requests cannot read another's items.
Serverless mobile backends
APIs on AWS Lambda where on-demand capacity follows real usage.
References
AWS references we design against
The documentation and controls behind the design choices on this page.
DynamoDB Developer GuideAWS Well-ArchitectedAWS IAMAWS KMSHIPAA eligible services
Facts and sources
Facts behind DynamoDB design
Limits and behaviors from the Amazon DynamoDB Developer Guide that shape the keys, indexes and pipelines we design.
Every partition in an Amazon DynamoDB table is designed to deliver up to 3,000 read units and 1,000 write units per second, so traffic concentrated on one partition key value can throttle while the rest of the table is idle.
Source: Amazon DynamoDB Developer Guide: partition key designA DynamoDB table can have up to 5 local secondary indexes, and the default quota is 20 global secondary indexes per table.
Source: Amazon DynamoDB Developer Guide: service quotasWith Time to Live enabled, DynamoDB deletes expired items within a few days of their expiration time without consuming write throughput, and AWS advises filter expressions to drop expired items from Query and Scan results until then.
Source: Amazon DynamoDB Developer Guide: Time to LiveTransactWriteItems groups up to 100 write actions into one all-or-nothing operation, and the aggregate size of the items in a transaction cannot exceed 4 MB.
Source: Amazon DynamoDB Developer Guide: transactionsDynamoDB Streams records a time-ordered sequence of item-level changes and keeps it for up to 24 hours, so stream consumers must keep up or lose older records.
Source: Amazon DynamoDB Developer Guide: DynamoDB Streams
Scope and cost
What drives the cost of DynamoDB consulting?
We do not publish prices. These are the factors we size on the scoping call.
Access patterns and entities
How many patterns the application has and how many entity types share a table.
New or existing table
A new design is a worksheet and a schema; an existing table adds a backfill and a switch-over.
Data migration
Moving data from a relational database means mapping rows to items and checking counts after the load.
Stream consumers
Search, events, analytics feeds and archives each add a consumer to build and monitor.
Multi-tenant isolation
Tenant keys, IAM conditions and tests that prove one tenant cannot read another's data.
Load testing
How realistic the traffic replay must be, including your busiest keys.
Frequently Asked Questions
It depends on how many entities and access patterns you have and whether data must move from an existing database. We agree the scope and the first deliverable, usually the access pattern worksheet and key design, on the scoping call.
Use it when items are read together and access patterns are known. Separate tables are simpler when teams, retention rules or permissions differ. Many systems end up with a few tables, each holding closely related items.
Yes. We read Amazon CloudWatch metrics and throttling events, find hot keys and scans, then add indexes or move items to new keys with a backfill and a switch-over that the application controls.
Often, for apps whose main reads are lookups by user, order or device, because there are no servers to manage and on-demand capacity follows traffic. If the product is mostly reporting, start with a relational database instead.
Amazon DynamoDB is on the AWS list of HIPAA eligible services, so it can hold PHI under a signed AWS BAA. We add KMS encryption, least-privilege IAM, point-in-time recovery and audit logging through AWS CloudTrail.
Yes. We feed a warehouse through DynamoDB Streams, exports to Amazon S3 or a zero-ETL integration with Amazon Redshift, so reporting queries never run against the production table.
Engineers may use AI tools to draft code or test data, but every key design and query is reviewed by a person and load tested against realistic traffic before release.