Perhaps using sqlite as the "backed" in that you build it like any other blog, so you get the simplicity of building it out, using one good sql framework etc.
But then, when you click "post" it rips through the database using a library of markdown -> HTML or whatever the case may be. Thhere can't be must overheard to a single include to pull in the html, but you could render the enter page. I just can't see php falling down too much with a few includes and functions being called to generate a header, the included rendered HTML, and a footer with some design elements.
It's not much fun building your own database out of flat files. I cut my teeth on a Mac only system that more or less only talked to Filemaker, which was only as fast as the actual screen could redraw and search out the data. It could be painfully slow.
In a way I am glad, as I learned how to do things and think differently when most were just running a "select * from foo where bar = 'x'" which was a 15 minute luxury I didn't have. There were no joins, no tables, you actually ran applescripts on the database and it returned the data somehow back to a web server on the Mac.
So we used the database on the backend, where admins could be more patient, or do more intricate things, but almost always generated out some HTML, so in the end, the site was semi-dynamic. I think I was doing "caching" of data as a result almost 15 years ago.
The rule was, no more than 2 database calls per page, ever. And you couldn't do things like update foo set name = 'me' where id = 1, because there was no exposed notion of a record id, it was internal, so you had to select name from foo where name = 'whatever' which would return the name, but also a RedID value, which you then got to run another query to update foo set name = 'me' where if =
Made me think a bit different.