Item — HN Reader

This article is a bit combative but I generally agree with the idea.

I use both MySQL and MongoDB in my daily work on a classifieds site that does a few hundred million pageviews a month. Both are pretty solid performers. The article is correct that with Mongo you just move the schema into the code (new versions not withstanding). I think it's nicer to have the schema on the database side but it's really just user preference. We typically end up creating a schema class and defining it up-front anyway. There is also a small subset of cases where not having a schema at all is actually a benefit.

Starting with a popular SQL engine is a really good tried and tested method though.

It's more than user preference in the long run; When your schema is encoded in the database (with triggers, constraints, foreign keys, the whole shebang), you can be sure that whichever way you access the database, it is still consistent.

When your schema is "in the code", even if you completely abstract it into a library, it means that the quick-one-off Ruby/Perl/C#/Python script will not have the integrity checks, and may corrupt your DB.