[winrid]

It's not an issue with size. It's an issue with race conditions. With Mongo I can update a.b and a.c concurrently from different nodes and both writes will set the right values.

You can't do that with PG JSONB unless you lock the row for reading...

[callalex]

Yes but that simplified write complexity means you are pushing a ton of read complexity out to your application.

[winrid]

What?? That's an insane argument. That's like saying if one client sets column X to 1 and another client concurrently sets SET y = 2, one client's writes will be LOST. It shouldn't, and it doesn't. If it did, nobody would use Postgres. This issue only exists with PG's JSON impl.

[callalex]

What?? That’s an insane way to describe what I’m talking about. Data/transaction isolation is very complex and extremely specific to every use case, which is why database engines worth anything let you describe to them what your needs are. Hence why when one client writes to Y they specify what they think X should be if relevant and get notified to try again if the assumptions are wrong. An advantage of specifying your data and transaction model up front is that it will surface these subtle issues to you before they destructively lose important information in an unrecoverable manner.

https://en.wikipedia.org/wiki/Isolation_(database_systems)

[winrid]

So updating one column on a table is destructive and can lose important information now? :D

How do you increment a value in a column while other people write to the database? You don't grab the whole damn row and rewrite it...

[winrid]

Also this statement:

> which is why database engines worth anything let you describe to them what your needs are

Contradicts your argument.

Mongo has atomic updates to update specific fields, or you can do replaceOne() etc to replace the whole document.

While PG only gives you "replace" with JSON.

So I guess postgres isn't worth anything. :)