> I mean would PostgreSQL really have had HSTORE if MongoDB never existed ?
Yes. The hstore extension was added to postgres in 2006 (commit 642194ba0cdc0aada9c99bf7712fcae5f3ac86d1), though it predates that date by quite a bit.
The first commit to MongoDB was in 2007
But that doesn't really matter. The reason I dislike MongoDB is that it shipped with unsafe defaults for years and caused people to lose data because of that.
For me, the one must-have feature of a database is that it will always allow me to read the data I've written to it (minus hardware defects). A database which can't fulfill that one feature doesn't qualify as a database in my book.
MySQL has issues there (it allows invalid data to be written and then "corrects" it and I've seen it corrupt table and index data multiple times without any evidence of hardware issues) and so does MongoDB (unless you changed the default config).
This has nothing to do with NoSQL vs. SQL (though, personally, I really like the flexibility for querying offered by the relational model) and everything with data integrity.
Original HSTORE was simply key/value pairs which has nothing to do with MongoDB. My point was that the popularity of MongoDB likely was a big incentive to add JSON support to PostgreSQL which they did only last year.
Lamest argument ever... Are you suggesting that the majority of postgres (say) installs are running default config with no changes? Or even better, Oracle?
I'm running multiple postgres installs (albeit small ones) in the default config.
Also, the default config of most databases is very conservative: You won't get speed, but you will get safety and it'll run on whatever hardware you throw at it.
Mongo on the other hand came with unsafe defaults and no obvious warning for people to change it. Additionally, after fixing the configuration, you would lose a lot of performance to the point of it being impractical to run mongo in a safe configuration.
Majority of installs or majority of transactions across all installs? I suspect that the majority of installs are indeed running default configuration, or at least close enough to default that the user wouldn't have looked closely enough to spot the kind of configuration issue being discussed.
Larger installs, which probably do account for the bulk of transactions, are more likely to have been tuned for speed, although probably keeping all of the safety settings at (or above) their defaults. But part of the point here is that in a safe configuration Mongo makes things slower than default.
The reason I dislike MongoDB is that it shipped with unsafe defaults for years and caused people to lose data because of that.
Surely when using any sort of new technology, you'd do some basic research about write concerns, durability, etc. first? If you just lazily adopt a new technology without reading the documentation, that seems like a bit if a recipe for disaster to me...
"Safe by default" is not a revolutionary concept. That's the reason I won't touch Mongo - not because of any specific bug or failing, but because it was designed from the outset without a consideration for what I consider a pretty fundamental engineering principle.
Yes. The hstore extension was added to postgres in 2006 (commit 642194ba0cdc0aada9c99bf7712fcae5f3ac86d1), though it predates that date by quite a bit.
The first commit to MongoDB was in 2007
But that doesn't really matter. The reason I dislike MongoDB is that it shipped with unsafe defaults for years and caused people to lose data because of that.
For me, the one must-have feature of a database is that it will always allow me to read the data I've written to it (minus hardware defects). A database which can't fulfill that one feature doesn't qualify as a database in my book.
MySQL has issues there (it allows invalid data to be written and then "corrects" it and I've seen it corrupt table and index data multiple times without any evidence of hardware issues) and so does MongoDB (unless you changed the default config).
This has nothing to do with NoSQL vs. SQL (though, personally, I really like the flexibility for querying offered by the relational model) and everything with data integrity.