Let me first say, I think all of the criticisms I am reading here are valid. That said, partitioning in PG still isn't great, and though it's better now than in say, v9.x, I'm not sure it's ever going to get where multinode NoSQL is without sacrificing core ACID that makes PG so great. I know it's not in keeping with the general HN dislike of Mongo, but if you have large scale data that has a stable partition key, data that you write and store authoritatively elsewhere like a relational DB, that you don't have to update with real time writes, but you need to do a lot of heavy reads of most of the fields, I think Mongo makes a lot of sense. To be clear, ALL of those things have to apply. And when you factor in ease of setup, adding new nodes, and training new devs that, doubt you will find a better solution.

There's still a rather large fanbase of Mongo on HN, it's just that we have to shut up most of the time.

I don't think anybody will downvote you just for making a point in favor of MongoDB, as long as it's valid.

If you are starting with things that are impossible to define (like the infamous phrase "internet scale") or are plain wrong, then you still don't have to shut up but maybe make sure you like your db of choice for the right reasons.

There are people who love mysql because they use PHP and others who love Mongo because they use nodejs. It's understandable: Those stacks have a lot of users and it's easier to get support. Nevertheless, it's not strictly a strong starting point when people are just discussing databases.

So, don't feel oppressed, just be clear with your reasoning.

> things that are impossible to define (like the infamous phrase "internet scale")

I like to think of that as "personal blog with a couple visits a day".

;)

I think Citus can be used effectively for that scenario now.

https://www.citusdata.com/

I doubt the guardian needs to shard though.

Mongo used to be a good fit for some projects when JSON-in-postgres wasn't a thing. I work on both Mongo and SQL-heavy projects and I see no reason not to do everything with SQL.

When you never need to work with two different documents at once, but need cheap scale. I once worked on a mobile game which saved player progress by uploading JSON to the server — the server never even parsed it, just saved directly to Mongo. And later retrieved it back when the player logged in.

That was the only time when I experienced a Mongo-based system which didn't suffer from any Mongo-induced problems.

Why even use a server and mongodb behind it for that when you can straight up save the document to Firestore from the game. No servers, no mongodb maintenence.

One is document-oriented database software while the other is a fully-managed document-oriented database-as-a-service, so not at all a useful comparison.

MongoDB offers a fully-managed database-as-a-service as well (Atlas), for what it's worth.

I swa a talk once from one of the facebook game companies who simply stored the player state in a file. There is nothing more simple! They simply loaded the files content into the memory as long as the player was playing and then serialized to file

Mongo is very, I say, agile-friendly. With SQL I should always mind schema migrations, and think about it both ways. If I have large enough RDBMS setup with sharding and replication - altering large tables may even became a complete show-stopper.

With Mongo and null-friendly languages (Kotlin, PHP) I can just start writing documents with new fields right away.

Like the parent said, Postgres supports unstructured data with json fields. The syntax is "clean enough" and you can easily migrate to a full column with a single query.

I like that I can easily build a view that includes "columns" from JSONB and normal table columns and clients are none the wiser. The clients get a consistent contract (the view schema) which can be backed by whatever tables make sense (or don't make sense but are used anyways).

I definitely appreciate the flexibility of a document store but I despise not having schemas for clients. Interface contracts reduce errors and ultimately make life easier for everyone. The database also has tons of information in RAM it can use to search and sort data, pushing those operations to the client balloons bandwidth requirements unnecessarily.

If you maintain clean layered code, accessing every collection via corresponding set of repository/data object classes - you will be just fine with MongoDB. But you better do that with SQL database too, anyway.

Mongo has schema enforcement, and if adding index it will keep and serve data straight from RAM.

Having used Django a lot in the past, migrations aren't that much of a problem with a decent tool. Mongo is still quite crap to work with in general.

Does it take hold purely because it’s easy to install and the company has a hyper-aggressive salesforce?

MongoDB is really easy to set up and the library API is really good. This provides the affordance in the start of a project where you don't have to think that much about system load from users.

You don't have to think that much about your relational model, so you can postpone all kinds of nasty questions about data integrity and multiplicity early on. This enables a team to move fast and break things.

The switch to something like Postgres comes later in the project where you know your requirements better and you need a system where you have more control over your data. You might even have a person responsible for maintaining your data for you on the payroll.

Personally, I usually just grab Postgres these days and use `json` columns for the documents and loosely fitting data, then drag out things into a more relational model as we go.

I didn't really have practical experience in mongodb. However, after checking latest mongodb documentation, it seems they have magically solved those issues in the last few years

how about these assumptions or myths?

a. treat it as in-memory document database. expect to lose data if it does not successfully write to disk periodically.

b. concurrent reading and writing. it claims that it is resolved for specific scenario in multiple document-level concurrency,while put a lock on single document issue.

c. Total data storage should not be bigger than memory, although it was fixed in v3.2 with new database engine.

d. multi document queries introduced in 4.2 and 4.4, however it is conflicting with their own recommendations that says Each document should be independent, denormalized data model.

I like their syntax, feel so natural. postgres jsonb syntax is unreadable, a bit hacky for me. should i be concerned with mongodb myths?

a) Depends if you run with replication and how you've configured your writeconcern (w and j values). https://docs.mongodb.com/manual/reference/write-concern/#ack...

This is giving you the choice where in the CAP triangle you want to be.

As you can see the default of w:1 and j:null when run in non replicated mode does not write journal to disk before ack. If you want better guarantees read some best-practice articles, most of them recommend w: majority, especially when run in replication.

c) no issue

d) $lookup works fine and is as old as 3.2, but as with any join, if you try to combine 2 tables with millions of rows each, performance will be bad. That said it's not as good as RDBMS here. No foreign keys or voodoo under the hood optimizations for example. Mongodb sales people will always say that you should model your data differently, without really giving good examples of such. But really - even if multi document queries exist, you should not continue modeling data as BCNF and think of mongo as a drop in replacement for RDBS, the domain should be suited for denormalized documents to begin with.

If you mean fetching/updating foreign-key-related documents by "multi documents queries", I wouldn't do it in RDBMS too. There's no special magic inside RDBMS made those queries much better than fetching related docs manually, but there are always some dark corner cases which will bring your database to full stop in most unfortunate times.

Why do you think some simple joins would risk to "bring your database"? It is code which is used all the time by tons of applications and not "some dark corner cases".

Try to figure out how it will work if both tables are sharded between partitions and some junior engineer will implement `LIMIT x SKIP y` REST pattern on that `SELECT FROM a INNER JOIN b` request with non-primary index sorting, for example.

There's a lot of beginner developers who have somehow not yet ran into problems that a proper relational OLTP would prevent, and love the initial ease of development that Mongo provides for small projects. Some of them go freelance as web developers and complete quite a lot of small projects for small clients without seeing any problems.

I’m storing data from a game’s api where each object has an unknown number of unique attributes. Each attribute can have a different type of data, including a nested structure. Additionally, each object’s data is subject to change massively between different versions of the game.