I think he's saying that if you have a large database in an rdb, adding the new column 'live' can take a prohibitively long time and kill access to the server, whereas a NoSQL db can add the new column without any large initial expensive operations on the db.
Generalise much? I agree that what the parent complains about is a MySQL problem but it's pretty disingenuous to just dismiss the whole "NoSQL" idea based on one misinformed comment on HN.
Nah, this keeps coming up on HN, and 99% of the time, the thing that "SQL databases" just can't do is something that DB2, Oracle, Sybase, Informix et al have done for 15 years or more.
Well, I don't know what you've been reading here, but there are plenty of things you can do with one of the systems listed in that article that you can't do, or can't do well/easily/cheaply, with any conventional RDBMS. The listed systems are very disparate, but here's a couple of examples:
In Redis you can read or write ~100k operations a second. You can do set operations, add, rem, member, list .. way cool if you can stomach the memory use. Lazy sync to disk. Hard to think of anything that could beat it for collecting stats or totals etc for high volume data streams.
In CouchDB you can do M/R style indexed views, like word counts. You can access the DB directly from HTTP, no special drivers - the DB is implemented as a web server. You can authorise via OAuth (soon), secure via TLS and proxy through squid. You can access, and replicate, from the other side of the world.
Tokyo Cabinet is over 10 times faster than MySQL as a simple hashtable, like, say, a session store, which is the first place most sites start having trouble with their DB. Tiny, bare bones, drivers for all major languages, network accessible. A no-brainer for simple storage IMO.
And all of these are completely free, unlike the cripplingly expensive commercial alternatives you mentioned - especially important for startups.
So .. basically I completely disagree, there's a lot of good things about these alternative DBs. Don't discount them just because you heard a few dumb ill-informed comments on sites like this, most people involved in non-RDBMS DB implementations know exactly what they're doing.
This should be a constant time operation on most databases, because existing rows are not touched. However, if you have lots of properties that are not indexed or directly queried, I suggest having a single JSON field for them.
(Disclaimer: not a db guy.)