Does the length of dynamoDB field name matter in terms of pricing

Question

In a dynamoDB with hundreds of millions rows, someone claims that we should use column name with least length - for example, instead of using name as field name, we should use n since these field names do matter in terms of pricing due to these amount of rows.

I took a quick look at pricing of aws DynamoDB and my understanding the pricing is based on the number of reads and writes (for both on-demand mode and provisioning mode) to dynamodb, no matter how many rows are stored in dynamodb. if this is true then the length of field name is not related to pricing and we can use normal names that are human friendly. am I correct?

Answer 1

While it's true that DynamoDB pricing is tied to the number of read/write requests, the length of attribute names does matter, although that's not related to the amount of data in DynamoDB, but to the size of a response to a request instead.

Billing for DynamoDB requests is based on so called request units. The DynamoDB pricing page explains how it works:

Read request unit: API calls to read data from your table are billed in read request units. DynamoDB read requests can be either strongly consistent, eventually consistent, or transactional. A strongly consistent read request of up to 4 KB requires one read request unit. For items larger than 4 KB, additional read request units are required. For items up to 4 KB in size, an eventually consistent read request requires one-half read request unit, and a transactional read request requires two read request units. For example, a strongly consistent read request of an 8 KB item requires two read request units, an eventually consistent read of an 8 KB item requires one read request unit, and a transactional read of an 8 KB item requires four read request units. See Read Consistency for more details.

Write request unit: API calls to write data to your table are billed in write request units. A standard write request unit can write an item up to 1 KB. For items larger than 1 KB, additional write request units are required. A transactional write requires two write request units. For example, a write request of a 1 KB item requires one write request unit, a write request of a 3 KB item requires three write request units, and a transactional write request of a 3 KB item requires six write request units.

So the length of attribute names becomes relevant, if your requests regularly return data which doesn't fit into a single request unit. Shorten the attribute names might help in that case to make it fit into less request units.

If you do for example a strongly consistent read request and your response is 4.1KB you'll be charged for two requests units, but if you manage to get the response size down to below 4KB by shortening the attribute names you'll be only charged for a single request unit.

I suggest you check the possible cost saving impact on your workload first, before you consider shortening the attribute names as speaking attribute names have a value too, by making the data easier to understand.