We're talking about data durability. When my SQL server crashes due to hardware failure I know that when I eventually get it back up and running the data will be consistent with at worst the last couple of transactions being rolled back.
What I'm saying is that I can go up to my SQL server and disconnect the power cord and my database will not be corrupt when I start it back up. Sure if your HDD gets taken out by a meteor then nothing will save you but that's why you have backups.
Not guaranteed. I have had more than one customer experience hardware failure, resulting in a corrupt or suspect SQL Server database, that was unrecoverable via normal means.
In each of the cases where the customer had a true standby system, implemented via replication, log shipping, or mirroring, they were able to failover with little (log shipping) or no data loss.
In the cases where they had a single, standalone server, the option was to restore the last known good backup, or sent the database files had to Microsoft for analysis and repair.
ANY system (RDBMS, NoSQL, or otherwise), should have a standby replica to prevent data loss. If you data is stored on a single machine, you are doing it wrong.
I'm not disagreeing with you, all I'm saying is that SQL Server databases are built from the ground up to resist data corruption and does exceedingly well at it. Not so with NoSQL data stores.
Yeah. There are several nosql backends which offer resistance to corruption under sudden failure. Bitcask, for example, is structured for on-disk data durability using some of the ideas for log-structured filesystems.
