BradCalder
For the cost of storage. The base price for Windows Azure Tables is $0.14/GB/month, and the base price for DynamoDB is $1.00/GB/month.
For transactions, there is the following tradeoff
• DynamoDB is cheaper if the application performs operations mainly on small items (couple KBs in size), and the application can’t benefit from batch or query operations that Windows Azure Tables provide
• Windows Azure Tables is cheaper for larger sized entities, when batch transactions are used, or when range queries are used
The following shows the cost of writing or reading 1 million entities per hour (277.78 per second) for different sized entities (1KB vs 64KB). It also includes the cost difference between strong and eventually consistent reads for DynamoDB. Note, Windows Azure Tables allows batch operations and queries for many entities at once, at a discounted price. The cost shown below is the cost per hour for writing or reading 1,000,000 entities per hour (277.78 per second).
• 1KB single entity writes -- Azure=$1 and DynamoDB=$0.28
• 64KB single entity writes -- Azure=$1 and DynamoDB=$17.78
• 1KB batch writes (with batch size of 100 entities) -- Azure=$0.01 and DynamoDB=$0.28
• 64KB batch writes (with batch size of 100 entities) -- Azure=$0.01 and DynamoDB=$17.78
• 1KB strong consistency reads -- Azure=$1 and DynamoDB=$0.05
• 64KB strong consistency reads -- Azure=$1 and DynamoDB=$3.54
• 1KB strong consistency reads via query/scan (assuming 50 entities returned on each request) – Azure=$0.02, DynamoDB=$0.05
• 64KB strong consistency reads via query/scan (assuming 50 entities returned on each request) – Azure=$0.02, DynamoDB=$3.54
• 1KB eventual consistency reads – DynamoDB=$0.028
• 64KB eventual consistency reads – DynamoDB=$1.77
• They both are NoSQL schema-less table stores, where a table can store entities with completely different properties
• They have a two attribute (property) composite primary key.One property that is used for partitioning and the other property is for optimizing range based operations within a partition
• Both of them have just a single index based on their composite primary key
• Both are built for effectively unlimited table size, seamlessly auto scale out with hands off management
• Similar CRUD operations
How Windows Azure Tables is implemented can be found in this SOSP paper and talk: http://blogs.msdn.com/b/windowsazurestorage/archive/2011/11/...
As mentioned by someone else, one difference is that DynamoDB stores its data completely in SSDs, whereas, in Azure Storage our writes are committed via journaling (to either SSD or a dedicated journal drive) and reads are served from disks or memory if the data page is cached in memory. Therefore, the latency for single entity small writes are typically below 10ms due to our journaling approach (described in the above SOSP paper). Then single entity read times for small entities are typically under 40ms, which is shown in the results here: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/...
Once and awhile we see someone saying that they see 100+ms latencies for small single entity reads and that is usually because they need to turn Nagle off, as described here: http://blogs.msdn.com/b/windowsazurestorage/archive/2010/06/...