Thanks, I've read that and will continue through the others.
One of the cases given could fit all the data in core, the other used BerkeleyDB for its smallish "database" data, cutting out SQL, and a GFS-like system for the large amount of BLOB archiving it had to do. It's the doesn't fit in core, and is changing data not archiving, case where it seems harder to use flat files since the DB server is a convenient place for concurrancy controls.
Check out the whole series.