Hacker News Reader

Comment by goenning | Hacker News Reader

I never used/tried MongoDB, what are the reasons people choose MongoDB over other DBs?

- Highly-flexible. Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast.

- Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries.

- Little to no concern over injection attacks (you have to go out of your way to create potential for them).

- Easier to write non-trivial queries than with SQL (IMO).

- Type-casting data can be done in code as opposed to with SQL you have to use inline, platform-specific functions like field_name::timestamp.

- A single source of truth for how to query and develop with it (with SQL, you're almost always developing against a flavor of it).

- Scales reasonably well (and easily) for a majority of use cases.

- No room for dogmatic fervor/confusion around a specific variety of MongoDB as there's only one variety.

> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast.

Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

It could be rephrased as "worry about them later" :P gotta get those returns on the VC money and pawn those issues onto the next team in 7yrs :)

Not necessarily. If you're utterly careless, sure. A MongoDB migration is far less of a headache than a SQL one (you're just writing code to map/replace values). With SQL, you have to be frustratingly surgical about everything which can slow momentum to a crawl (read: punishment for mistakes in the migration is far worse than with MongoDB in my experience).

I completely agree! Kind of preaching to the choir :)

> Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

If you're careless with your data, yes. "With great power comes great responsibility."

Being careful with my data is exactly why I use a strongly typed RDBMS in the first place.

So basically nothing Django and a postures db can't do.

It was an early player when everyone thought NoSQL document databases solved every problem.

They did solve many problems, and then they caused many more problems...

At first at least, haven't checked in on that in awhile

And now everyone knows RDBMS solves every problem. Especially when it's SQLite.

Mongo is the main nosql choice. Mongo is great if you think a flexible schema is good. Mongo is not great if you think a flexible schema is bad. That sums it up

This is too reductive, you can essentially have flexible schemas with most modern relational databases and without the downsides of document-based DBs.

In 99% of the cases, even if you need a flexible schema, PostgreSQL will remain the best choice.

Unless it's not.

it probably is though

I use it on-prem (well, on a VPS). It stores JSON documents, and it's easy to work with. If your data looks like a tree, it works pretty well, also for large documents. If you depend on relations between documents, you're better off with an SQL database, but note that for many cases --I'd say practically all mundane cases-- there's really no need for relations the SQL way. MongoDB also does relations, but a bit more convoluted.

Postgres does all that plus 100x.

I've also tried SQLite, but they didn't do large documents that well. And the project was started before I was aware Postgresql had json support.

But what's the advantage of Postgresql in this case?

But the horizontal scaling is easier with Mongo than Citus.

But you don't need to horizontally scale if you use a beefy Postgres instance. Horizontal scaling is a problem created by using an inefficient DB in the first place.

I have DB clusters with masters with a terrabyte of ram. Going beyond that is a PITA with warming up cache, backups, and so on. There is a reason there's a huge industry for shared databases.

Also, query for query, Mongo isn't going to be that much slower than PG, and faster for some usage patterns...

*sharded

It's pretty easy to start with. MQL is also pretty easy to understand + MongoDB kinda makes it fun.

Note: I work at MongoDB

And Atlas has a free tier! It's been powering my site (https://bongo.to) for years for a total price of $0. Incredible!

What's the update internally here? How long this been going on for? Any juice?

It's a really great alternative to firebase for mobile apps. Works pretty nicely with Realm so you get offline first db with powerful syncing. All the benefits of realm on the edge device with the power of the mongo platform. I dismissed mongo atlas for years because "mongo", until I finally gave it a chance. Overall been pretty pleased.

> It's a really great alternative to firebase for mobile apps.

Isn't firebase built on top of mongoDb?

We use MongoDB in conjunction with RealmDB to build an offline first mobile app. For this specifically it works very well. You basically define which parts of your document collection should be synced to which device, for example based on a query that contains the user id. MongoDB takes care of syncing the right data to the right device when internet connection is available. On the device, the data is stored locally in RealmDB, which represents the other side of the sync.

This is not easy to do with PostgreSQL, which we use for all other scenarios requiring a DB.

Easy, flexible scheme nosql, plenty of baked in features. Has it's place, and many times when it would not be a good choice too.

Enterprise support, lots of documentation, does what it says it does.

Reply on news.ycombinator.com