I think my own answer would be that a database system is very often the right solution if you know what you're doing with them. In this situation, diagnosing p

I think my own answer would be that a database system is very often the right solution if you know what you're doing with them. In this situation, diagnosing performance problems is quite easy (thanks to diagnostics), concurrency is certainly easier, and scaling can be easier too - because problems like concurrent file access for writing are hard in a flat-file situation and easy on the database, and that's exactly the kind of problem you often run into when you scale. Unfortunately, when you don't know what you're doing with them, they're basically a black box where magic happens, and you don't know how to fix any problems that occur. The thing is, that applies to many things. When you don't know what you're doing with concurrent file access, you'll run into even bigger problems than you will on an RDBMS - just last week I was in fact rewriting an otherwise-competent colleague's code, because concurrent read/write to files caused massive unrecoverable corruption issues. I don't think your wordpress comparison is apples to apples - wordpress is known to be dog-slow, and if you tried similar access patterns over file systems it would be at least as bad. There's little incentive for them to fix it, though, because wordpress sites are read-mostly, and all you have to do to fix all your problems is stick one of the wordpress caches in front of it. Frankly it boggles my mind that they don't ship with a cache on by default. There's absolutely a place for no-db - if your content is static or write-once, doesn't need indexing over, and you can guarantee that those requirements won't change. In this case, there's no need at all to use a db, and it will simplify your life not to. I'm writing such a site as we speak, in fact! If you have dynamic content, well, I'd use a DBMS personally. tl;dr: understanding how to use RDBMSs will make the average software engineer's life much easier. edit: Just a note on SQLite specifically: SQLite can be slow compared to the common file system trick of write new temporary file -> rename, because the file system trick (on ext3 at least) doesn't require an fsync. It does mean that the change is not guaranteed durable, but often for browser data that's OK! An equivalent in database-land would be not writing every single transaction to the transaction log when it commits. That means that on a crash you lose everything that hasn't hit the disk yet, but you maintain consistency. Pre 3.7 SQLite this wasn't supported because SQLite didn't use write-ahead logging, which meant you had to fsync to maintain consistency. I believe in WAL mode this behaviour is easily available now though!