Ask HN: What is your opinion on mongo db?

[kamalkishor1991]

I always thought relational dbs are always better except may be really narro usecase of horizontal scalability Please share your opinion? Maybe I am missing something obvious. Lot of people seem to like mongo db a lot and most of the reasons does not make much sense to me.

[eindiran]

In my experience, it depends on what data you are trying to store. Is your data composed of JSON documents which may be partially or fully unstructured? Are you pretty sure this isn't going to change? Then consider using Mongo. Otherwise, the decision may (will) bite you in the ass at some point when you end up needing some features of a relational database. The flip side of this is that it can be a boon to use Mongo if you are consuming data that may suddenly change without notice.

Some amount of future-proofing can be done in the case where your data is currently unstructured JSON, but you may need what a relational database offers in the future by using something like Postgres with the JSON data type. But there are tradeoffs between Postgres + JSON and Mongo that you may need to play with to decide which is better for your usecase.

[NicoJuicy]

https://martendb.io/documentation/documents/customizing/dupl... :)

[legostormtroopr]

Pros: its webscale.

Cons: No transactional consistency, you lose all the Pros of relational databases.

Unless you absolutely know why you want to use Mongo (and there are cases, probably), you don't want to use it.

[superflit]

My cynical opinion.

Mongo is a JSON repository.

Good for: When you have to transact with an ever changing and evolving API that you do not have control.

Looks good on Resume, Looks bad on Costs.

[karmakaze]

MongoDB used to suck in many ways. Since ver 3.2 with the WiredTiger storage engine, it only sucks in the ways that you'd expect using a schema-less document store. WiredTiger is kind of like InnoDB in how MySQL used to suck before it.

Using JSON with either PostgreSQL (JSONB) or MySQL is probably a much better bet. If you scale to the point that you really need sharding and not just multi-master and/or read replicas, then you can probably afford the migration.

[_bxg1]

The couple of times I've made something with Mongo, I've always just found myself defining a schema in the source code anyway. As long as some code eventually reads the data there's no such thing as "no schema", there's just "multiple" or "less precise" schemas: https://utcc.utoronto.ca/~cks/space/blog/programming/Databas...

All this is to say: from a software engineering standpoint I like defining my schema rigidly at the DB level. The added flexibility that NoSQL provides is not something I actually find desirable. That said, I've never had to share one of these DBs with other programmers.

[NicoJuicy]

I used to prefer relational db's, but ever since DDD I've been switching my opinion.

Currently, my go to library is MartenDb which has the best of both worlds.

Documents with duplicated properties for queries.

https://martendb.io/documentation/documents/customizing/dupl...

If you want a more detailed answer, let me know, since it could take a while to write everything down :p

The alternative for this with mongo db is an elastic search on top of it for queries. But yeah, that doesn't feel good/overkill.

[bradknowles]

It’s fine, so long as you want to store random assortments of random documents, in small collections, and you can get all that into a single machine.

As soon as you need to scale it up by sharding or replicating, you’re fucked.

[nine_k]

I've seen Mongo the company making technical decisions which I find reckless (like no write confirmation by default). Since it was not once and not twice, I decided that I just want to stay away from them.

Do I want smaller scale JSON DB? Postgres fits perfectly. And it works until surprisingly large scales, unless your update load is massive.

Do I need a truly distributed HA DB with JSON support? Well, Cassandra used to be fine.

[brianmcc]

You might find this a useful discussion and article from a couple of years back:

https://news.ycombinator.com/item?id=18717168

[toomuchtodo]

Use PostgreSQL instead.

[najarvg]

For most bread and butter small-medium enterprises, PGSql + JSON or PGSql + Time-series (timescaledb) can handle any use case

[oblib]

I'm not really familiar with mongo db but I have been working with couchdb for awhile now.

I just posted a "Show HN" of a simple demo app I made that uses CouchDB installed on the client side. CouchDB will run a Mac, Windows, and Linux desktop PCs.

The demo uses PouchDB.js to interact with CouchDB. PouchDB is really pretty sweet.

Take a look at the demo and play around with it a bit. There are two web pages that are both self contained. One sets up a user and db, the other demonstrates crud routines.

https://cherrypc.com/app/editor/setup.html

https://cherrypc.com/app/editor/index.html

Also check out the PouchDB docs: https://pouchdb.com/