Is the issue really commercial DBs? It seems like most projects that use a (SQL) DB are solving a problem they shouldn't have, and doing it in an overly complicated manner.
If a project truly requires ACID to the point there's a sensible worry about the disk holding the right data, I'm pretty sure I'd save money (and hair) paying for a medium server and a license to deal with that (particular) data. It's really rare to run into a problem that requires both that level of reliability and needs performance beyond what a medium server can reasonably handle. I think most projects are far far more likely to screw the data in some other way, so one could question if it's worthwhile.
I'm saying this having had to implement true ACID transactions (and replication) myself. It's a ton of work getting it right through all of the layers of libraries, os, filesystems, controllers, and drives. It's hard to trust user-level programs to be able to do it given an arbitrary stack below them. I place more trust in a system that can cut through some of those layers (or call across campus and control how some of those layers work) and work with particular hardware.
I place even more trust in someone screwing the data up at a higher level and it really not mattering nearly as much as people make it out to anyway. Even in "critical" cases like storing financial transactions, it usually just results in people having to call around or get in and fixing a few things.. which is WAY cheaper than the huge cost to lower the odds by 90%, and you've got to be prepared to do that anyway.
If a project truly requires ACID to the point there's a sensible worry about the disk holding the right data, I'm pretty sure I'd save money (and hair) paying for a medium server and a license to deal with that (particular) data. It's really rare to run into a problem that requires both that level of reliability and needs performance beyond what a medium server can reasonably handle. I think most projects are far far more likely to screw the data in some other way, so one could question if it's worthwhile.
I'm saying this having had to implement true ACID transactions (and replication) myself. It's a ton of work getting it right through all of the layers of libraries, os, filesystems, controllers, and drives. It's hard to trust user-level programs to be able to do it given an arbitrary stack below them. I place more trust in a system that can cut through some of those layers (or call across campus and control how some of those layers work) and work with particular hardware.
I place even more trust in someone screwing the data up at a higher level and it really not mattering nearly as much as people make it out to anyway. Even in "critical" cases like storing financial transactions, it usually just results in people having to call around or get in and fixing a few things.. which is WAY cheaper than the huge cost to lower the odds by 90%, and you've got to be prepared to do that anyway.