My experience is that this is true of every database system (relational or non-). The thing is that they all break in different ways at different points, and so the smart thing to do is make choices based on that information.
The stupid thing to do is write blog posts about how Software Package X sucks and nobody should use it for anything.
I work with databases in extremely high OLTP workload environments since 20 or so years.
We're talking enterprise products, mostly Sybase, some Postgresql and very little Oracle.
Have I encountered bugs?
Sure, tons of them. Some of them grave enough to render the specific version of the database software unusable in the context of the project I worked on.
However, in all this time I probably dealt with no more then 3 - 5 corrupt databases, none of them went corrupt due to a database bug. Usually it was related to hardware failure,
Arguing that database corruption is inherent in the design of the product is, from a database perspective, beyond the pale.
A database "breaking" is absolutely not the same as a database blasting your data into corrupt confetti.
If you actually go through the various stuff posted, you find a recurring theme: people who lose data fall into a pattern of "well, they told me not to do this, but I did it anyway, so now it must be their fault".
Which, I think you'll find, is a far cry from "database corruption is inherent in the design".
But hey, learning that sort of thing would require reading; much easier to jump on a bandwagon, badmouth a product and downvote anyone who disagrees, amirite?
And everything is wonderful! Complains and criticism should be removed from the world.
Nice job putting words in my mouth.
Look, I know it's fashionable right now to hate on Mongo for whatever reason, but the simple fact is that everything has a breaking point. Saying "I ran into this product's breaking point, therefore nobody should ever use it" (the gist of many of the recent posts) is frankly stupid; instead, we should be asking when and how and why something breaks when evaluating it, since that'll give us an idea of what fits specific use cases.
Comments
Mongo is fine until it's not.
My experience is that this is true of every database system (relational or non-). The thing is that they all break in different ways at different points, and so the smart thing to do is make choices based on that information.
The stupid thing to do is write blog posts about how Software Package X sucks and nobody should use it for anything.
I work with databases in extremely high OLTP workload environments since 20 or so years.
We're talking enterprise products, mostly Sybase, some Postgresql and very little Oracle.
Have I encountered bugs?
Sure, tons of them. Some of them grave enough to render the specific version of the database software unusable in the context of the project I worked on.
However, in all this time I probably dealt with no more then 3 - 5 corrupt databases, none of them went corrupt due to a database bug. Usually it was related to hardware failure,
Arguing that database corruption is inherent in the design of the product is, from a database perspective, beyond the pale.
A database "breaking" is absolutely not the same as a database blasting your data into corrupt confetti.
So...
If you actually go through the various stuff posted, you find a recurring theme: people who lose data fall into a pattern of "well, they told me not to do this, but I did it anyway, so now it must be their fault".
Which, I think you'll find, is a far cry from "database corruption is inherent in the design".
But hey, learning that sort of thing would require reading; much easier to jump on a bandwagon, badmouth a product and downvote anyone who disagrees, amirite?
And everything is wonderful! Complains and criticism should be removed from the world. Ain't it?
And everything is wonderful! Complains and criticism should be removed from the world.
Nice job putting words in my mouth.
Look, I know it's fashionable right now to hate on Mongo for whatever reason, but the simple fact is that everything has a breaking point. Saying "I ran into this product's breaking point, therefore nobody should ever use it" (the gist of many of the recent posts) is frankly stupid; instead, we should be asking when and how and why something breaks when evaluating it, since that'll give us an idea of what fits specific use cases.
But maybe that's too practical.