Not based on my testing — with a 1kb item I was only able to achieve 167 RPS. Of course optimistic locking is more cost efficient because it only requires one write, but there are many situations where pessimistic locking is required.

The choice between optimistic locking and pessimistic locking depends on the cost of retrying and chance for conflict. My article is specifically about when you want to use pessimistic locking. There is a larger throughput penalty for DDB transactions as you cannot achieve the full RPS as expected.

A simple scenario is a user opens an item for modification. You don’t want the item to change out from under them, so you need some form of locking. Transactions don’t really do anything for you here. Plus there is a large throughput penalty for using transactions: dev.to/aws-builders...

I used this to spin them up recently and it was very easy github.com/CloudSnorkel...

Fairly sure you pay the same cost (twice the WCU per item for all items in the transaction) whether the transaction succeeds or fails. Returning the item attributes due to a condition check failure doesn’t cost anything extra. You can also specify ReturnConsumedCapacity to get the exact costs.

I saw some neat things that haven’t been announced yet show up in the CloudWatch console