DynamoDB One Year Later: Bigger, Better, and 85% Cheaper…

A) I don't get it - Is it a proprietary database maintained and provided only by Amazon? If that's the case, then isn't that a terrible trade-off for a business to get locked into a proprietary database on a proprietary platform?<p>I agree it could save you a LOT of cash, but, assume you ran Mongo or PostgreSQL, then if you aren't satisfied with provider A, you can dump them and migrate your data to provider B, let alone all the modifications you can make on top of these Open source databases...Sure, you may face downtime, but that's not as bad as being locked into a proprietary database that you have no control over.<p>Someone please correct me if I'm wrong..<p>B) How does this compare to LinkedIn's Voldemort (which seems to be inspired from Amazon's Dynamo[1])? Voldemort has a lot of positive feedback from real world applications running at Scale, I guess.<p>[1]<a href="http://blog.linkedin.com/2009/03/20/project-voldemort-scaling-simple-storage-at-linkedin/" rel="nofollow">http://blog.linkedin.com/2009/03/20/project-voldemort-scalin...</a>

The 75% reduction in indexed storage cost is a big win, from my perspective.<p>At $0.25 / GB / month it's now roughly 2.5x the cost of EBS disk-based storage, and you're only charged for data as you use it, with no need to reserve it ahead of time.<p>The alternative of running postgres or mongodb on an ebs-backed ec2 instance just got a lot less attractive to me.<p>Way to go, Amazon!

I'm really excited about the price reduction and the reserved throughput possibilities. Over the past six months I slowly but surely migrated most of the core data storage for the startup I work for to DynamoDB and I have been very satisfied with the performance. That said I agree with the post that DynamoDB isn't suited for every use case, just like MySQL and other relational databases aren't suited for every use case. We are still using MySQL for log tables and other tables in which we need to do complex queries over time ranges with tests on multiple properties.<p>The sweet spot is combining DynamoDB and a relational database into a seamless system that lets you use the power and scalability of DynamoDB when all that is needed is a simple lookup, and the complex queries of SQL when you need a detailed time range based report.

I worked with dynamoDb maybe 6 months ago and found some of the restrictions very limiting. In MongoDb the current max size for a document is 16mb, and there are workarounds for bigger data. In dynamoDb a single item cannot exceed 64kb, ever.<p>They used to only support unsigned integers, so happy hacking when storing unix time before 1970. However, this seems to have been fixed.<p>Personally, I will hold off another year before using dynamoDb again. It takes time for a project to mature.

When Amazon makes Dynamo installable and usable outside of the walled city of AWS I'll give it a try. Dynamo just gives me the heeby jeebies of vendor lockin.

TFA talks about the fact that SQL simply doesn't scale to volume as big as the ones that companies like Amazon need to deal with.<p>It's not the first time I've read this: Google also has similar problems and fixed it with a DB (or DBs ?) of their own. In Google's case, AFAICT, it's also a gigantic key/value store on which monstrous map/reduce are done.<p>My question is simple: up to which amount of data and for which use cases do SQL still work? In other words, at which point do you need something <i>else</i> than SQL simply because SQL ain't cutting it anymore?

Every three words in this article is DynamoDB. I'm sure this is an interesting post but I stopped reading due to DynamoDB stuffing. I really don't need your brand hammered on my brain in order to realize how great your product is.