
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...](https://martendb.io/documentation/documents/customizing/duplicated_fields/)
:)

------
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...](https://utcc.utoronto.ca/~cks/space/blog/programming/DatabasesAlwaysSchemas)

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...](https://martendb.io/documentation/documents/customizing/duplicated_fields/)

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](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/setup.html)

[https://cherrypc.com/app/editor/index.html](https://cherrypc.com/app/editor/index.html)

Also check out the PouchDB docs: [https://pouchdb.com/](https://pouchdb.com/)

