He writes:
"I have no idea how to use a key/value store database properly."
You don't need a database, or object-store or anything fancy to get decent performance for a personal blog. I use Chronicle and it spits out flat files; lighttpd uses sendfile(2) and everything is fast. FWIW, his blog software is one he wrote in Clojure:
http://github.com/briancarper/cow-blog/tree/0.2.0
For read-intensive applications, Sqlite3 would do just well.
This write-up should not influence anyone with respect to the (de)merits of MySQL, TokyoCabinet or Postgres.
I agree, this post shouldn't influence anyone. Not sure why it was submitted to HN.
A person hacking on his own stuff, just to try out things, is hacker news to me.
The only point he makes is that the APIs for non-relational DBs are much too simple and limited, so you end up building lots of code on top to do the most trivial things.
What we really need is a way to generate indexes or materialized views on these DBs in a standardized way (see CouchDB, for an example).
As for why it's on the homepage, I don't think it belongs here either. The intended audience was rather more narrow than HN.
While k-v stores and other NoSQL solutions have many great, valid use-cases, I expect there are many other people who switched to NoSQL stores on the basis that they were "faster" only to discover that they needed many of the features they'd left behind in SQL databases.
A follow up article about the query architecture in all three implementations could be interesting: how he failed with a relational DB, how he failed with a key/value DB, how he succeeded with a relational DB. An article like that could have an interesting story arc and may include information applicable to other developers.
(Disclaimer: I don't know what I'm talking about. If someone else had mentioned this idea, I wouldn't have said anything.)