DynamoDB.
AWS’s serverless key-value database for known query patterns and large or spiky traffic.
Talk to us about DynamoDB
Key features
What DynamoDB does well.
ACID transactions
Transactional reads and writes can change several items across tables, all succeeding or all failing.
Secondary indexes
Global and local secondary indexes let one table answer queries on keys other than the primary key.
Point-in-time recovery
With point-in-time recovery switched on, a table can be restored to any second within a recovery period of up to 35 days.
Conditional writes
A write can be made to succeed only if the item is in an expected state, which prevents lost updates.
What we build with it
Plan the questions first, then the table.
DynamoDB returns items by key in single-digit milliseconds, with no servers to manage and capacity that follows traffic. The trade is that the table has to be designed around the questions the app will ask. We write those access patterns down first, then choose the keys and indexes that answer each one.
Serverless back ends
Tables behind Lambda functions, with on-demand capacity that rises and falls with traffic.
Sessions and short-lived data
Time-to-live settings that delete old items automatically.
Workflows that react to changes
DynamoDB Streams triggering functions when items change, for notifications, search updates or audit logs.
When it’s the right choice
DynamoDB suits AWS products with predictable access patterns and high or uneven traffic, where paying per request beats running a database server.
When we’d pick something else
Ad hoc queries and reporting are hard, since every query needs a key or index planned in advance. We often stream the data to a separate store for analytics, or choose PostgreSQL when the questions keep changing.
Our DynamoDB services
How we can help.
Access pattern design
A written list of the app’s queries, then keys and indexes chosen so each one is a single request.
Table reviews
Checks for hot partitions, unused indexes, scans and capacity settings that cost more than they should.
Analytics exports
Streams or exports that copy table data to a store where reports and ad hoc queries are practical.
Infrastructure as code
Tables, indexes, streams and backups defined in Terraform so every environment matches.
How we work
Starting a DynamoDB project.
Review what exists
Code, data, hosting and the people who maintain it, before any DynamoDB decision is made.
Agree the approach
A written scope: what changes, what stays, the risks and how we will know it worked.
Build in reviewable slices
Working increments your team can test, rather than one large delivery at the end.
Hand over or stay on
Documentation and access for your team, or a defined support scope if you want us to keep going.
Where AI fits
AI in data work.
Vector search where your data lives
PostgreSQL with pgvector (including on Supabase and Neon), MongoDB Atlas and Redis can all store embeddings next to your records, so search does not need a separate system.
Knowledge assistants ↗Access rules before retrieval
Row-level security in PostgreSQL limits what an assistant can retrieve to what the signed-in user is allowed to see.
Knowledge assistants ↗
Where it stops: Embeddings are derived from personal data too, so they need the same retention and deletion rules as the records they came from.
Where it fits
Related expertise.
- APIs & integrations Connect your product to the systems your team relies on, with clear contracts and handled failures.
- Cloud architecture Choose and structure cloud services around your product’s data, access and operating needs.
- Infrastructure as code Define environments in version-controlled code, so changes are reviewed and drift is easy to spot.
Common questions
DynamoDB questions.
Single-table or multiple tables?
It depends on how the data is read. One table saves requests when entities are fetched together; separate tables are easier to follow when they are not. We decide per product.
Can DynamoDB serve users in more than one region?
Yes. Global tables replicate data across AWS regions so people read and write close to where they are. We plan what the app should do when two regions update the same item.
Further reading
- A database for every pull request: preview environments that work How to give each pull request its own database branch, with safe data, tested migrations and automatic clean-up.
- Firebase, Supabase or a custom back end: how to choose How to choose between Firebase, Supabase and a custom back end by data shape, access rules, cost, exit paths and skills.
- MySQL 8.0 has reached end of life: planning the move to 8.4 What MySQL 8.0’s end of life means, and how to plan, test and roll back an upgrade to MySQL 8.4 LTS.
