[notacoward]

Loading the set of files needed to satisfy a request is equivalent to a database query. Databases and file systems have to deal with similar issues when looking up a single item, so there's a clear correspondence there. The difference is that a database can do a JOIN but a file system can't (directory traversals really aren't equivalent). In that case any such logic would have to be in the client-side JS, fetching objects and quite likely imposing even more load than an SQL query would have. Being able to shut down that database process is good in a lot of ways (especially security) but reduced total load isn't necessarily one of them. You might just be shifting load to the the web server and file system. That's why I said the generator part is as important as the static part. That solves the result-aggregation problem at edit/compile time instead of request/run time, which is good regardless of whether the back end is a database or a file system.

[ak39]

The loading of static files for HTTP is significantly different from accessing the same data via databases. The biggest difference is the need for a CLI (call level interface) connection object in db access. And those things are resource hungry operations (authentication, prototocol management etc). Most times you have to pool connection objects which in itself is a resource cost.

The DB is truly the scalability bottleneck.

[notacoward]

The overhead you're talking about doesn't seem to be in the database itself, but in crappy (possibly language- or framework-specific) interfaces to them. That's an application issue, and I was talking about system issues.