4 ms·

If that's the case, then it's probably purely marketing. I had no idea PostgreSQL offered a comparable option.

smt88 9y ago
Something I don't think is mentioned elsewhere: other databases have shipped with Mongo compatibility. This means you can migrate from Mongo to something better without changing your code. The most mainstream and interesting of these is Cosmos: https://docs.microsoft.com/en-us/azure/cosmos-db/connect-mongodb-account https://docs.microsoft.com/en-us/azure/cosmos-db/connect-mon... (Cosmos is actually one of the most interesting DB products available for production right now, in my opinion.)
deepsun 9y ago
Yep, I benchmarked it myself, JSONB column type in PostgreSQL worked faster for me than same data in MongoDB (both reads and writes).
btown 9y ago
JSON wasn't stable in Postgres until 2012, whereas the "web scale" memes for Mongo started after its initial release in 2009. Mongo indeed had better marketing and a first mover advantage, and it never let go.
- chx 9y ago
  And it wasn't usable until practically 2015 (2014-12-18 if you so want).
- cervo 9y ago
  Early versions of mongodb locked the entire database server for every single write. Later versions locked the entire database for every single write. Only since Mongo 3.0 does MMAP only lock a single collection for a write and is WiredTiger available to offer you MVCC. And even in the MongoDB world materials it advertised now you can use more of your hardware.... Granted you could always shard, though that gets very expensive very quickly. Meanwhile postgresql had MVCC all along and its write speed was always faster than mongo on a single server basis. And you always could serialize data that changed into text fields as xml/json/csv/some other format. Mongo was mostly great marketing and a lousy product. Over time it has gotten much better. Mongo 3.2 is a way way way better product than mongo 1.x. But marketing did capitalize on a lot of hype which made no sense. Developers enjoyed just serializing their objects (the ones who didn't think of doing this into a text column in a relational db) and for the ones who did not need 'web scale' they had no idea about the severe concurrency issues introduced by mongo's writes. And for the rest there are plenty of posts about hacking around it or switching from Mongo to something else.
cervo 9y ago
Even prior to the JSON type you always could have serialized the data for the sample to some kind of string JSON/XML/CSV and put it in the column. But I think the one thing NOSQL data stores e.g. HBase/Cassandra and to a lesser Degree MongoDB has taught me is to pay attention to the tradeoffs number of rows, size of index, etc...

Something I don't think is mentioned elsewhere: other databases have shipped with Mongo compatibility. This means you can migrate from Mongo to something better without changing your code. The most mainstream and interesting of these is Cosmos: https://docs.microsoft.com/en-us/azure/cosmos-db/connect-mongodb-account https://docs.microsoft.com/en-us/azure/cosmos-db/connect-mon... (Cosmos is actually one of the most interesting DB products available for production right now, in my opinion.)

deepsun 9y ago

Yep, I benchmarked it myself, JSONB column type in PostgreSQL worked faster for me than same data in MongoDB (both reads and writes).

btown 9y ago

JSON wasn't stable in Postgres until 2012, whereas the "web scale" memes for Mongo started after its initial release in 2009. Mongo indeed had better marketing and a first mover advantage, and it never let go.

chx 9y ago
And it wasn't usable until practically 2015 (2014-12-18 if you so want).
cervo 9y ago
Early versions of mongodb locked the entire database server for every single write. Later versions locked the entire database for every single write. Only since Mongo 3.0 does MMAP only lock a single collection for a write and is WiredTiger available to offer you MVCC. And even in the MongoDB world materials it advertised now you can use more of your hardware.... Granted you could always shard, though that gets very expensive very quickly. Meanwhile postgresql had MVCC all along and its write speed was always faster than mongo on a single server basis. And you always could serialize data that changed into text fields as xml/json/csv/some other format. Mongo was mostly great marketing and a lousy product. Over time it has gotten much better. Mongo 3.2 is a way way way better product than mongo 1.x. But marketing did capitalize on a lot of hype which made no sense. Developers enjoyed just serializing their objects (the ones who didn't think of doing this into a text column in a relational db) and for the ones who did not need 'web scale' they had no idea about the severe concurrency issues introduced by mongo's writes. And for the rest there are plenty of posts about hacking around it or switching from Mongo to something else.

cervo 9y ago

Even prior to the JSON type you always could have serialized the data for the sample to some kind of string JSON/XML/CSV and put it in the column. But I think the one thing NOSQL data stores e.g. HBase/Cassandra and to a lesser Degree MongoDB has taught me is to pay attention to the tradeoffs number of rows, size of index, etc...