Goodbye Tokyo Cabinet, hello PostgreSQL

"I switched to TC to begin with because I was using SQL wrong, and it was too slow and clumsy. Once I figured out how to use SQL correctly, it was a no-brainer to go back."<p>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.

Moved a personal blog from MySQL to TokyoCabinet to Postgres? Why?<p>He writes:<p><i>"I have no idea how to use a key/value store database properly."</i><p>You don't need a database, or object-store or anything fancy to get decent performance for a <i>personal</i> blog. I use Chronicle and it spits out flat files; lighttpd uses sendfile(2) and everything is <i>fast</i>. FWIW, his blog software is one he wrote in Clojure:<p><a href="http://github.com/briancarper/cow-blog/tree/0.2.0" rel="nofollow">http://github.com/briancarper/cow-blog/tree/0.2.0</a><p>For read-intensive applications, Sqlite3 would do just well.<p>This write-up should not influence anyone with respect to the (de)merits of MySQL, TokyoCabinet or Postgres.

While I like reading informative articles about hackers mastering their tools, this article doesn't have a lot of general purpose information, or mastery of tools.<p>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.

That guy has no clue how to use a non-relational DB (he even admits it) and he uses a DB that is wrong for his task and wonders why it's so hard.<p>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.<p>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).

Why is this on the front page? I could understand it IF he switched to PostgreSQL because it outperformed Tokyo Cabinet, but he switched back simply because he finally learned SQL. This isn't about technology, it's about his understanding. This story is lame.

People who don't understand database/relational-stuff should not touch db-related work.

Why not use both, especially if you're using your blog as a technical playground? Every time you update the document in the Tokyo cabinet, you could make appropriate changes to the PostgreSQL tables, and that way you wouldn't have to worry about writing clever queries for tags.<p>(Disclaimer: I don't know what I'm talking about. If someone else had mentioned this idea, I wouldn't have said anything.)

Point number 2 for why not to use TC is not very strong. If you need help installing a database perhaps you need to learn a little bit more before managing a webserver.