1 For our business (not web related at all) we write our own database software. Processing time is phenomenally fast.   It's a hell of a lot of work, but the results have kept our little business going for over 30 years. I've worked for them for 20 years this year. (of course it helps that the guy I work for is an absolute genius... LOL).

2 A lot of the complexity of databases comes from the combination of ACID semantics (atomic, consistent, something*, durable), availability, and scalable performance on disk-based storage.

As soon as you can throw one of those requirements away, things start loosening up.  If you're a bank (say) and must have ACID, high availability, and scalable performance, you can still achieve that easily by installing a huge RamSan (hundreds of gigabytes of battery-backed, mirrored RAM that looks like a disk) but is a thousand times faster.  If you don't need full ACID, there's a ton of optimisations you can use.

For Minx I care a lot about the D in ACID, and about availability and performance.  But if a post gets half saved (or saved twice) in the event of a crash, that doesn't matter (as long as we don't crash too often).  Banks can't do that, but blogs can.  That means I can mostly do away with transations, which makes things a lot simpler.  And I already have an SSD in our server that can do 3500 IOPS - and 24GB of RAM for 15GB of databases - so I don't need to optimise the disk routines like crazy.

So I think it's actually feasible.  I'm willing to put a week or two of effort into it to find out, anyway.

* Isolated, but I had to look it up.