The quotes from the CEO are misleading, implying MongoDB is document-based and PostgreSQL is 100% relational. This is not true, PostgreSQL has had JSON support for quite some time.
Mongodb certainly isn't doing it.
Their entire value proposition boils down to
create table docs (
doc jsonb
);Postgres jason types are blobs in an RDBMS, and jsonb is to be avoided in almost all cases.
I am not a MongoDB cheerleader and I am a huge fan of Postgres when SQL is appropriate, but equating an ACID style DB with a key value store misses the point.
But it is horses for courses, people using MongoDB for acid transactions when support landed in v4 is where most of the problems came from.
When deployed in their core domains, both work better than the hacks implemented to artificially make them competitors.
You might be uniformed (or misinformed) on this topic. JSONB is not just a "blob" in Postgres. It's a first-class value type with full query-ability and indexing support.
[0] https://www.postgresql.org/docs/current/functions-json.html
https://www.postgresql.org/docs/current/datatype-json.html
> JSON data is subject to the same concurrency-control considerations as any other data type when stored in a table. Although storing large documents is practicable, keep in mind that any update acquires a row-level lock on the whole row.
Concurrency is far more nuanced in MongoDB and storage of documents has far fewer side effects than jsonb.
The ad hominem is ironic with someone claiming RDBMS and key value stores are equivalent.
Is the concurrency "nuance" that Mongo DB allows 2 updates to a JSON doc to race with each other?
> keep in mind that any update acquires a row-level lock on the whole row.
Yes! Thank you Postgres developers. This is what _professionals_ do.
Professionals consider weigh the tradeoffs consistency vs partion tolerance, availability, synchronous vs asynchronous communication implications etc...
Nothing here is a silver bullet, it is about choosing the least worst option for a data domain.
We are in the cloud era, which is by its nature distributed.
The era of vertically scaled monoliths is mostly over for most people.
The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be.
Hint: even your ATM card doesn't use ACID, and many needs can improve performance, availability and resilience by not paying the cost of ACID transactions.
It is a far more complex subject than your posts suggest.
I'll send you some books to read, too.
> Hint: even your ATM card doesn't use ACID
I guarantee you that the actual database handling those ATM transactions is ACID-compliant. The banking institution itself couldn't even be certified by the FDIC or the Comptroller of the Currency (OCC) if their database system wasn't, at the very least, ACID compliant.
Out-of-band transaction resolution is a completely separate topic and has nothing to do with databases, or ACID, or anything else.
You're kinda out of your depth here...
Why's that?