5 ms·
My experience says that the issue is not differences, but bad architectural decisions. Most applications out there are glorified CRUDs. They are perfectly servi
by asimuvPR 10y ago
My experience says that the issue is not differences, but bad architectural decisions. Most applications out there are glorified CRUDs. They are perfectly serviced by SQL databases. NoSQL fits a smaller set of systems whose scope is mostly passing data around. PostgreSQL now supports JSON as a datatype and allows querying it. Works beautifully. No need for MongoDb at all.
- chucky_z 10y agoI will argue _against_ MongoDB all day, but there is most certainly a time and place for it. If you have a real firehose of data, don't care too much about the accurateness, and really need good speed... MongoDB is not an awful choice.
- eyelidlessness 10y agoHow well does it stand up against other "NoSQL" solutions that compete in the same space? My impression has been that it tends compete poorly with a number of other solutions for data integrity, and my intuition is that its appeal is correlated to the proliferation of JavaScript and the convenience of interoperating with it.
- chucky_z 10y agoFrom my experience, the problem is not how does any NoSQL solution stand up vs. any other NoSQL solution. The question to ask is "What caveats affect me the least?" and then go with that NoSQL solution. In the case of MongoDB, the biggest issue (at least in the past) is that the caveats simply aren't known well, or at all! Compare this to something like Elasticsearch, which is well-known (and well-documented) to have data loss in certain situations.
- omginternets 10y ago>MongoDB is not an awful choice Frankly I think it's still an awful choice given it's broken replication model.
- bonesmoses 10y agoCould you explain a bit more about this? From what I can see, it's just journal consumption. That's basically how Postgres does it, too.
- omginternets 10y agoAphyr explains it better than I every could: https://aphyr.com/posts/284-jepsen-mongodb https://aphyr.com/posts/284-jepsen-mongodb :)
- bonesmoses 10y agoVery informative. Thanks!
- eyelidlessness 10y agoMy understanding, which is admittedly minimal, is that MongoDB provides some conveniences around partitioning and distributing your dataset that Postgres does not without additional work. Simply supporting JSON accommodates MongoDB's approach to schemas (not having them; er, pushing constraints to application code), but doesn't address the distribution concern. How well does MongoDB support this need, and how hard is it to achieve equivalent results with Postgres? What are the drawbacks?
- twblalock 10y agoMongo's partitioning/distribution/replication does not work as well as it should. In particular, my team has seen several serious bugs pertaining to replication in release versions that were so bad, they should have blocked the release.
- elmigranto 10y agoSide note: you can have constraints, `check`s, indexes and triggers on `json` and `jsonb` columns in Postgres. In fact, you can have everything other data types have. So "no schema" or "moving schema to app level" doesn't have to be the case, when using PG.
- bonesmoses 10y agoExactly. With Postgres, you can add CHECK constraints to enforce specific keys, with any level of nesting desired. So an INSERT could reject a document for having missing fields, fields of improper type, etc. It all depends on how strict you want to be.
- Kiro 10y agoIs here something like mLab for Postgres?