5000 per second with --innodb_flush_log_at_trx_commit=0, which only writes the log to disk once per second.
The MySQL documentation claims that this configuration does crash-recovery correctly, though you may lose the last second's worth of transactions.
Robert, did you test MySQL with a parallel load? To give it the best chance at maximizing tps, it will need to be able to combine multiple pending transactions in a single write. Also, can you tell if it's updating it's b-trees? (if not, it may not be able to sustain these rates)
And yet somehow that gets translated into "get rid of that database."
On the up side, you are going to learn a lot about essay writing, and about how concepts do/don't get through to people. These are very valuable skills.
It's true that PostgreSQL uses a write-ahead log, but it's still going to do that seek when it checkpoints, correct? I don't think that it will be able to sustain high transaction rates (100,000 tps for small transactions should be very doable). If you find that this isn't true and that someone has demonstrated these rates, let me know -- it would certainly be good news.
As for being wrong, that's one of the privileges you lose with celebrity. Everything you write in your blog is going to be preceded by "The guy who wrote gmail says..." When you say something that looks like it might become a popular misconception, guys like me will jump up and down, scream, and tear at our hair. Or maybe we'll just post terse, cold, unfriendly corrections. We still like you, though.
My main issue with your post is the way it comes across as saying databases are overengineering for 99% of web sites, but mainly deals with a performance issue that won't matter for 99% of web sites. I would have no problem if you framed it as high tps vs low tps for certain classes of application, not as simplicity vs overengineering. Using a relational database is a fine default choice for web apps today, just as you expect to have an OS on your server by default.