databases for storage
Using databases for the primary storage of your content is a known antipattern.
Databases are all a pain to maintain (i.e. highly human-time inefficient - see DBA tax below), and more fragile than the file system.
For any content you care about it, don't put the primary copy in a database.
(this likely deserves its own canonical definitional article)
The term DBA tax has been introduced to quickly reference the extra overhead you as a person incur by depending on any system that uses a database for primary storage. If you maintain any such system, you have to spend some amount of your time being a database administrator (DBA), hence that time spent is referred to as the DBA tax that you are incurring.
In particular, a database is yet another space of things.
Everyone already deals with a file system. Why deal with yet another space?
The following are aspects of the DBA tax - hassles of:
All extra crap (thus tax) compared to "just" using the file system.
All databases have a DBA tax.
Experience and evidence shows DBA tax exists as well. People lose things (and have them corrupted) in databases all the time, far more often than in file systems. This is because databases always require extra "magic" for backups etc.
E.g. search the web for people complaining about having to backup their WordPress databases before upgrading their WordPress install.
Even in databases that use only a single file (e.g. SQLite?), that "one file" is still uninspectable, as opposed to simple HTML you can always look at in a browser.
There are many reasons why an uninspectable/random/binary magic file format is fragile, whereas HTML is an inspectable file format that many tools can read/write, including a simple text editor. In particular:
Most databases tend to be biased/tied to a particular programming language (or operating system) as well - more unnecessary constraints - trapping you into a particular platform (language or OS).
In contrast, every language / OS has flat file APIs. Nearly all have DOM Document APIs as well.
... Bad news: MySQL barfed all over the table holding my posts. ... 
And I'm pretty sure that happened when Rackspace hard reset my machine due to swapping.
Note: apparently postgres doesn't have that problem.
Databases are essentially dead for anything but caching/performance needs for high volume sites. Examples:
In both search use-cases the DBs should be a cache/query store, the real data should still be in flat files (e.g. .md, HTML, etc.)
Even though databases are fine for rebuildable caches, that's still solving an optimization problem.
Any design that depends on databases is optimizing prematurely - before you have any idea what the performance characteristics of the system are.
Rather than using a database for storage, use open well established formats like HTML + microformats, and if you really like how databases let you access them, instead build a database-like API on top (of said HTML + microformats files).
With HTML+microformats2 + a microformats2 parser, we already have a database-like API that gives you data back from HTML.
It's likely that eventually we'll come up with something resembling a database / storage API on top of an HTML+microformats2 file.
SQLite tax avoidance
Q: Is SQLite a way to avoid the DBA tax?
How are database file formats random
Q: How are database file formats random?
Q: Isn't MySQL pretty portable?
Follow-up: Q: Isn't MySQL trivial to port via: mysqldump ... | scp | mysql ?
Still not convinced
Q: Still not convinced that databases for storage are an anti-pattern or about the DBA tax.