The One DynamoDB Mistake That Keeps Costing Me

I have made the same DynamoDB mistake on three different projects. Each time I swore it was the last. Each time, six months later, I discovered I had done it again. The mistake is ignoring access patterns at modeling time and paying for it at query time.

The Pattern I Keep Repeating

Early in a project, I sketch a data model based on the entities: users, posts, categories, subscribers. The schema looks clean. Each entity gets a partition key and a sort key. Relationships are implicit.

Then the first query comes in: list all posts in a category, sorted by date. The clean model has no efficient answer for this. I add a GSI. Then another. Then another. Three GSIs later the cost model looks worse than a relational database would have been.

The Root Cause

DynamoDB rewards access-pattern-first modeling and punishes entity-first modeling. Every resource on DynamoDB design says this. I read the resources. I still default to entities-first because the entity model looks cleaner on a whiteboard.

The Checklist I Now Run First

Before sketching any DynamoDB schema, I now write:

• Every read pattern, with frequency estimate
• Every write pattern, with frequency estimate
• The cardinality of each entity
• The hottest partition in the worst case

Only then does the schema get drawn. Every time I skip this step I regret it within three months.

Single-Table Design, Conditionally

Single-table design is the canonical DynamoDB pattern. It works beautifully when access patterns are well known up front and stable. It breaks when access patterns evolve or when multiple teams own different entities.

For solo consulting projects, single-table is usually the right answer. The access patterns are knowable, the entities are few, and the tradeoff favors predictable cost.

The Cost Shape

Entity-first DynamoDB with three GSIs costs roughly three times access-pattern-first DynamoDB with zero or one GSI, for the same workload. Over a year on a modest project, that delta is the difference between $60 and $180 a month, or between a free-tier fit and not.

What I Do Differently Now

• Write the access pattern list before the schema
• Review it with the client before any code lands
• Revisit it at every new feature request
• Treat GSI creation as an architectural event, not a patch

The Escape Hatch

If the access patterns are genuinely unknowable up front, DynamoDB is the wrong choice. Use Postgres until patterns emerge, then migrate. I ship this answer to clients more often than I used to.

Alex DeBrie's DynamoDB book is the single resource I wish I had internalized two years earlier.