Things I learned using DynamoDB (and Athena)

Amardeep Kumar — Fri, 11 Sep 2026 11:44:00 +0000

I have been working with DynamoDB for quite some time in our NestJS + TypeScript backend, so this week instead of picking some random topic, I thought I will just write down a few things I actually learned while using it in real features.

1. Design around your queries, not your data

Coming from SQL, my habit was to normalise everything into separate tables. DynamoDB does not work like that at all. You can only query efficiently using the partition key and sort key. There are no joins, and scanning the whole table is slow and costly.

So the real skill is to first decide your access patterns, like get item by id, get all transfers of a store, etc, and then design your keys and GSIs (Global Secondary Indexes) around them. For one feature I built recently (a stock transfer module), a single table with 3 GSIs covered every query the app needed - by source store, by destination store and by status. Once you start designing this way, reads stay super fast no matter how big the table grows.

2. Small data mistakes become big problems

One lesson I learned the hard way - be consistent with data formats. We store dates as ISO strings like 2026-09-11T10:30:00.000Z. Once a date got saved as a numeric epoch timestamp instead, and everything downstream that expected a string (reports, lambdas, views) broke. DynamoDB is schemaless, so nothing stops wrong data from getting in. Basically your application code IS the schema, so validate at write time.

3. The analytics problem, and Athena

DynamoDB is great for the app, but very bad for questions like how many transactions happened last month grouped by status. There is no SQL, no group by, nothing.

We solved this with a small pipeline that syncs DynamoDB data to S3 automatically:

DynamoDB Streams -> Lambda -> SQS -> S3 -> Athena

Enable streams on the table, so every insert or update sends an event with the new item. A Lambda picks that event and pushes it to SQS, so sudden traffic spikes do not overload anything. Another Lambda writes the records to S3, partitioned by table name. And then Athena lets us run normal SQL directly on those S3 files - joins, group by, everything DynamoDB itself cannot do.

The best part - to onboard any new table into analytics, we just enable the stream on it. No code changes needed.

Final thoughts

DynamoDB and SQL databases are not competitors, they solve different problems. Use DynamoDB for fast app queries, and pair it with something like Athena for analytics. And in a schemaless world, discipline about data formats is not optional - it is the schema.

DEV Community: Amardeep Kumar

Things I learned using DynamoDB (and Athena)

1. Design around your queries, not your data

2. Small data mistakes become big problems

3. The analytics problem, and Athena

Final thoughts