Choosing DynamoDB capacity mode for an app almost nobody uses yet

My side project shows which study rooms in our library are free. On a busy day during finals it gets a few hundred requests. On a Saturday in the middle of the semester it gets roughly zero. I spent way more time than I'd like to admit going back and forth on DynamoDB's two capacity modes for something this small, so here's where I landed.

With provisioned capacity you choose read and write units ahead of time and pay for them by the hour whether you use them or not. Auto scaling helps, but there's always a floor you're paying for.

With on-demand you pay per request and don't plan capacity at all. AWS cut on-demand throughput prices in half  in late 2024, and a lot of the older blog posts I was reading were written before that, which made them more confusing than helpful.

For traffic this low and this uneven, on-demand means I pay for the requests I get and nothing else. Provisioned would mean paying for capacity during all the hours when nobody is looking for a room, which is most hours.

My one real worry with on-demand was a bug. If my frontend ever got stuck in a retry loop, on-demand would happily scale up and bill me for all of it. Then I found out you can set a maximum throughput on an on-demand table. I set a low cap, so if something goes wrong the requests get throttled instead of turning into a surprise charge. That setting is what actually made me comfortable.

From what I've read, provisioned starts to win when traffic is steady and predictable enough to keep utilization high, and you can switch modes later if that ever happens. For now, on-demand plus a throughput cap plus a billing alarm is the setup where I think about the database the least. For a side project I work on between classes, that's worth more than saving a few cents.