I had some random fortune come may way last year in the form of a four month stint to finish off and deliver on a DynamoDB based project. The project was handed over to me just as the requirements of the project had changed enough, in retrospect, for a column-family database such as DynamoDB to serve as a painful reminder of a key reason why we use RDBMSs; SQL. Fowler and Sadalage  say it best below Section 10.4 When Not To Use.
RDBMS impose high cost on schema change, which is traded off for a low cost of query change; in Cassandra [Column-Family Databases], the cost may be higher for query change as compared to schema change.
As you can gather, the requirements of the project I completed, albeit with the power of SQL sorely missed, was a prime When Not To Use example. But the experience gained is priceless, as is the trade off quote below for future software architecture specifications.
It is worth noting one more thing that Fowler and Sadalage say in the same cited Section, which matches my experience exactly. In essence they do not recommend using Cassandra, and this also goes for DynamoDB in my mind, for prototypes or tech spikes since during the early stages it is unlikely that one will know how query patterns will change. As query patterns change, with DynamoDB, my experience was that the column family design had to change. The effect of such family column design change is summed up by Fowler and Sadalage succinctly yet again  below.
This causes friction for the product innovation team and slows down developer productivity.
Yep, I was at the receiving end of the query pattern change burn, but am still grateful for the experience.
 Fowler, Martin; Sadalage, Pramod J. (2012-08-08). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence (p. 109). Pearson Education (US). Kindle Edition.