I've always been interested in NoSQL databases, but I never understood the advantage of a schema-less design. Migrations make it so you can change the structure of your data at any time so you really aren't locked into anything. Even ignoring that, your data has to have some kind of shape to it (a kind of ad-hoc schema) and you still have to deal with data whose shape has changed (which migrations take care of for you).
Migrations get expensive and risky when you have lots of data. Being able to do them incrementally is sometimes worth the complication of maintaining code to read older versions. A traditional database doesn't let you do that; you have to execute an "alter table" statement all at once.
yup. once upon a time we had a MySQL db on commodity hardware doing around 6K QPS with over 100M rows in the biggest table. you can't do much to it without taking it offline, and even then you have no idea if/when the migration will complete.
There is no advantage of a schema-less design, because there is always a schema. It is just a matter of whether the schema is made explicit and enforced, or whether it is scattered all over the application code.
it can make it much easier to do on-demand migrations: in massive online apps, a large percentage of data is essentially 'dead' - it's unlikely anyone will ever access it again. and massive online apps (call it 'web-scale' if you will ;) can accumulate a lot of data. the systems they're discussing make it easier to migrate data as needed instead of at once (which sometimes isn't even possible if the infrastructure is really being pounded).
The advantage of schemaless is that if you are adding extra attributes (most common database change) then you don't have to do any migration. And migrations have a long history of having side effects as well as requiring Database/Operations teams involvement if you work in the enterprise.
And as I mentioned before the "shape of your data" is quite often defined in your application anyway.
