[999900000999]

Simple.

Postgres is hard, you have to learn SQL. SQL is hard and mean.

Mongo means we can just dump everyone into a magic box and worry about it later.No tables to create.

But their is little time, we need to ship our CRUD APP NOW! No one on the team knows SQL!

I'm actually using Postgres via Supabase for my current project, but I would probably never use straight up Postgres.

[codr7]

If learning SQL is hard, maybe software isn't the best choice of career.

Writing code and creating good software requires a lot of mental clarity and effort; that fact is never going to change, not even with AI.

[999900000999]

Billions upon billions of value have been created just upon the premise that SQL is hard.

Firebase by and almost every NoSql technology is based upon this.

[SEJeff]

Postgres supports JSONB natively. It literally speaks mongo line protocol and you can shove unstructured json into it.

It has supported this since 9.4: https://www.postgresql.org/docs/current/datatype-json.html

[999900000999]

I don't necessarily agree with the above justifications, but in my experience this is basically why teams pick Mongo.

It's easier to get started with.

[codr7]

Now there's a truth about MongoDB, it's easy to get started with.

But why is that the top priority?

[FridgeSeal]

Because some devs and teams prioritise “get to prod” above literally all else.

Maintainability? Secondary. Security? Secondary. Data-integrity/correctness? Secondary.

[SEJeff]

It’s hard to disagree with you on that part. PG is definitely not free to get starts with and requires a bit of setup (hello pg_hba.conf).

[winrid]

Yes but updating nested fields is last write wins, and with mongo you could update two fields separately and have the writes succeed, it's not equivalent.

[SEJeff]

Can you provide an example or documentation please?

[winrid]

When you write to a postgres jsonb field it updates the entire JSONB content, because that's how postgres's engine works. Mongo allows you to $set two fields on the same document at the same time, for example, and have both writes win, which is very useful and removes distributed locks etc. This is just like updating specific table columns on postgres, but postgres doesn't allow that within columns, you'd have to lock the row for updating to do this safely which is a PITA.

[chpatrick]

Even as a JSON document store I'd rather use postgres with a jsonb column.

[tiltowait]

Why is that? I found Postgres's JSONB a pill to work with beyond trivial SELECTs, and even those were less ergonomic than Mongo.

[chpatrick]

Because you get the convenience of having a document store with a schema defined outside of the DB if you want it, along with the strong guarantees and semantics of SQL.

[chpatrick]

For example: let's say you had a CRM. You want to use foreign keys, transactions, all the classic SQL stuff to manage who can edit a post, when it was made, and other important metadata. But the hierarchical stuff representing the actual post is stored in JSON and interpreted by the backend.

[cryptonector]

I thought this was sarcasm till the last sentence. Now I'm not sure.