Tangential to the topic, but this is important: every schema update MUST be considered part of the app / database / backend / system source code, and as such it should be properly and formally applied, versioned and backed up. In the simplest case, you can store a version number in the database itself, every update applies to a certain version # X and advances to another version # Y, and every update is stored in its own source file (updateX.sql for example).
Would be nice if DBMSs offered primitives specifically for schema version management, but I guess there could be many different use cases, and it's very easy to roll your own.
Is that why? I was under the impression that Facebook doesn't use the relational properties of MySQL because they couldn't get the performance out of it because of their scale, a problem a lot of advocates of the non-relational model dont' seem to have in my experience.
No, it can't. Sorry, it absolutely can't.
> If you add a default value it locks the table and re-writes it. > However, if you don't add a default value postgres will perform the operation instantly.
And in MongoDB you don't have to change anything in the DB (hence, no downtime). It's all in your code.
Yes, I can add a field in PGSQL, then my ORM quits on me (because I can't have a optional field, of course). Or I can use hand written SQL at which point it adds a couple of months to my schedule.
Or I can use migrations + ORM like Ruby migrations or South (Django). They will blow up for anything slightly more complex.
I also can't use the old version of the DB, so my old backups just became more troublesome to recover.
And that's why Facebook and others don't user relational anymore. Sure, you can use MySQL or PG, but the real data is stored in a text or binary blob.