5 ms·

Article is more an introduction of Mongo to Postgres users, rather than comparison. And yeah, anything's better than Mongo :)

raverbashing 10y ago
> And yeah, anything's better than Mongo :) Yeah I guess keeping to their comfort zone while keeping a sense of superiority is easier :)
- elmigranto 10y ago
  I started with Mongo, used it for little bit over 2 years. Then new project used Postgres (2 more years). After that I got a chance to work with Couch. Whenever I encounter Mongo nowadays, it's either simulating multi table joins on app level, or inventing locking with Redis. Part of the issue is people storing relations in NoSQL just because, but I can't think of any use cases where Mongo wins over other NoSQL solutions. Perhaps you have some?
  - raverbashing 10y ago
    > but I can't think of any use cases where Mongo wins over other NoSQL solutions For small deployments, and when you don't have to worry about (many) relations between tables it should be ok to use Mongo Maybe Cassandra is better in some cases, or PostgreSQL with JSON And of course Redis in a lot of different situations I don't know what you mean by "inventing locking with Redis" but it doesn't seem like anything I would advise doing either with Mongo or Redis
  - lloyd-christmas 10y ago
    Image storage * When working on any type of image-based data science, it's incredibly easy to manage, it's fast, and meta data is incredibly convenient. The drivers are pretty consistent and readable across languages. Assuming that you know javascript, it's a pretty quick and easy set up to add a light weight node server with an image cropper on the front end, then set up a python app to do your data processing once you're done munging. I set that up any time there is an image-related competition on kaggle or setting up HAL-like robots on my raspberry pi to mess with my roomates: "I'm sorry Dave, I can't let you cook that". * all you "OMGZORS USE A FILE SYSTEM!" can keep your mouth shut. This is drastically faster and much more manageable for the use-case.
Lio 10y ago
I note the smillie but could you actually expand on that comment for someone who is only really familiar with relational databases? I've recently become interested in using PouchDB (a CounchDB implementation) for syncing offline content between a user's browser and server where the content is based on a set of fixed documents. I believe that MongoDB can provide similar replication tricks. Once on the server I would expect to extract the data from the documents into a relational warehouse database (probably PostgreSQL as it's one of the databases I know best). A document store _seems_ like the right tool for the job but could expand on why something like Mongo or Couch is a bad idea for situations where you're just storing/syncing documents?
- elmigranto 10y ago
  > why something like Mongo or Couch is a bad idea Couch is fine, other NoSQL is fine. It's just Mongo I don't like: - weak, if any, guarantees on data consistency and safety; - poor API. If you need anything more complicated than `findOne`, there are at least 3 unrelated syntaxes with major differences that are not compatible; - performance is not what marketing team says it is. Even at home JSON turf, Postgres is pretty comparable. If you have data and queries that will benefit from document store, go for it. But don't choose only based on marketing. There are many more rant on the web, I like this one: http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/ http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
- raverbashing 10y ago
  Look up on CouchDB problems, several of its customers have given up on it (more than MongoDB it seems) It's not a bad idea, MongoDB has a lot of undeserved hate (some of it deserved, but the minority), however I'm not sure it would do syncing as you want automatically (CouchDB is probably closer out-of-the-box to what you want)

raverbashing 10y ago

> And yeah, anything's better than Mongo :) Yeah I guess keeping to their comfort zone while keeping a sense of superiority is easier :)

elmigranto 10y ago
I started with Mongo, used it for little bit over 2 years. Then new project used Postgres (2 more years). After that I got a chance to work with Couch. Whenever I encounter Mongo nowadays, it's either simulating multi table joins on app level, or inventing locking with Redis. Part of the issue is people storing relations in NoSQL just because, but I can't think of any use cases where Mongo wins over other NoSQL solutions. Perhaps you have some?
- raverbashing 10y ago
  > but I can't think of any use cases where Mongo wins over other NoSQL solutions For small deployments, and when you don't have to worry about (many) relations between tables it should be ok to use Mongo Maybe Cassandra is better in some cases, or PostgreSQL with JSON And of course Redis in a lot of different situations I don't know what you mean by "inventing locking with Redis" but it doesn't seem like anything I would advise doing either with Mongo or Redis
- lloyd-christmas 10y ago
  Image storage * When working on any type of image-based data science, it's incredibly easy to manage, it's fast, and meta data is incredibly convenient. The drivers are pretty consistent and readable across languages. Assuming that you know javascript, it's a pretty quick and easy set up to add a light weight node server with an image cropper on the front end, then set up a python app to do your data processing once you're done munging. I set that up any time there is an image-related competition on kaggle or setting up HAL-like robots on my raspberry pi to mess with my roomates: "I'm sorry Dave, I can't let you cook that". * all you "OMGZORS USE A FILE SYSTEM!" can keep your mouth shut. This is drastically faster and much more manageable for the use-case.

Lio 10y ago

I note the smillie but could you actually expand on that comment for someone who is only really familiar with relational databases? I've recently become interested in using PouchDB (a CounchDB implementation) for syncing offline content between a user's browser and server where the content is based on a set of fixed documents. I believe that MongoDB can provide similar replication tricks. Once on the server I would expect to extract the data from the documents into a relational warehouse database (probably PostgreSQL as it's one of the databases I know best). A document store _seems_ like the right tool for the job but could expand on why something like Mongo or Couch is a bad idea for situations where you're just storing/syncing documents?

elmigranto 10y ago
> why something like Mongo or Couch is a bad idea Couch is fine, other NoSQL is fine. It's just Mongo I don't like: - weak, if any, guarantees on data consistency and safety; - poor API. If you need anything more complicated than `findOne`, there are at least 3 unrelated syntaxes with major differences that are not compatible; - performance is not what marketing team says it is. Even at home JSON turf, Postgres is pretty comparable. If you have data and queries that will benefit from document store, go for it. But don't choose only based on marketing. There are many more rant on the web, I like this one: http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/ http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-ne...
raverbashing 10y ago
Look up on CouchDB problems, several of its customers have given up on it (more than MongoDB it seems) It's not a bad idea, MongoDB has a lot of undeserved hate (some of it deserved, but the minority), however I'm not sure it would do syncing as you want automatically (CouchDB is probably closer out-of-the-box to what you want)