Maybe I'm just weird, but all of this drama around a database does not make much sense to me.
Because it's the most painful point of tech. If you need to change programming languages to meet a latency requirement, that sucks. If you find your servers go down and they need rebooting, that sucks too. If you lose your data, it's gone and you can never get it back.
The troll did well to zero in on this. You don't really know how stable a database is under certain conditions until you start hitting the roadblocks. With NoSQL databases, you have less time in the wild vs RBDMSs, so anything which indicates there are hidden gotchas are going to set potential adopters' teeth on edge.
Even better, with database issues, you don't know about them until you have them, so you often do have to rely on folk knowledge about how well they turn out in practice after months/years of deployment.
and it is a easily trollable target as well. Had he tried to to attack durability on probably any other database, it probably would not have worked as well as it did.
Whether its a troll attempt or not, remains to be seen, but I completely agree with this specific, albeit very generic, part of the text.
> Databases must be right, or as-right-as-possible, b/c database mistakes are so much more severe than almost every other variation of mistake. Not only does it have the largest impact on uptime, performance, expense, and value (the inherit value of the data), but data has inertia. Migrating TBs of data on-the-fly is a massive undertaking compared to changing drcses or fixing the average logic error in your code. Recovering TBs of data while down, limited by what spindles can do for you, is a helpless feeling.
Because it's the most painful point of tech. If you need to change programming languages to meet a latency requirement, that sucks. If you find your servers go down and they need rebooting, that sucks too. If you lose your data, it's gone and you can never get it back.
The troll did well to zero in on this. You don't really know how stable a database is under certain conditions until you start hitting the roadblocks. With NoSQL databases, you have less time in the wild vs RBDMSs, so anything which indicates there are hidden gotchas are going to set potential adopters' teeth on edge.
Even better, with database issues, you don't know about them until you have them, so you often do have to rely on folk knowledge about how well they turn out in practice after months/years of deployment.
It was a well-targeted troll.