> That can get messy and unless security is tight, some developer or admin could muck something up on the filesystem This isn't a great reason not to use a fil

> That can get messy and unless security is tight, some developer or admin could muck something up on the filesystem This isn't a great reason not to use a filesystem--it's a reason not to let staff have at the filesystem like cowboys, and not to avoid replicating and backing up the keys and values on the filesystem as if they are really important. That said, there isn't really a solid replacement for a database transaction involving both fields + blob, but most situations are okay with, say, stowing a blob in S3, and later making a half-hearted attempt to delete it if the associated database transaction fails.