Hacker News Reader

Comment by asimuvPR | Hacker News Reader

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.

View on HN

My 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?

Side 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.

Exactly. 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.

Mongo'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.

I 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.

>MongoDB is not an awful choice

Frankly I think it's still an awful choice given it's broken replication model.

Could 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.

Aphyr explains it better than I every could: https://aphyr.com/posts/284-jepsen-mongodb :)

Very informative. Thanks!

How 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.

From 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.

Is here something like mLab for Postgres?

Reply on news.ycombinator.com