4 ms·

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

by a57721 2y ago

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.

petcat 2y ago
json/jsonb, hstore, ltree, btree/gin/gist, enum types, nested record types... the list goes on and on. PG is _very_ hard to beat. Mongodb certainly isn't doing it. Their entire value proposition boils down to create table docs ( doc jsonb );
nyrikki 2y ago
Document-oriented databases are a subclass of the key-value store. 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.
- petcat 2y ago
  > Postgres jason types are blobs in an RDBMS, and jsonb is to be avoided in almost all cases. 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/functions-json.html
  - nyrikki 2y ago
    Fighting with autocorrect, 'json' type is a blob with a path search in front. https://www.postgresql.org/docs/current/datatype-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.
    - petcat 2y ago
      > Concurrency is far more nuanced in MongoDB and storage of documents has far fewer side effects than jsonb. 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.
      - nyrikki 2y ago
        Document updates are atomic, with replica sets. Reads will be eventually consistent. 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.
        petcat 2y ago
        > The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be. 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...
- simonw 2y ago
  "jsonb is to be avoided in almost all cases" Why's that?
- DemocracyFTW2 2y ago
  A key/value store is easy to build in Postgres, just define a table with a key column and a value column, that's it. Given that both key and value can be of datatype JsonB or BLOB, there's no restriction in generality, just, you know, aptness for the purpose. Now if you do that, you can—in Postgres—define additional structure or choose a different model entirely if your KV store turns out to be less ideal for whatever you want to do. MongoDB does not give you that choice.
bdjsiqoocwk 2y ago
Postgres is 100% relational AND supports JSON.

by a57721 2y ago

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.

petcat 2y ago

json/jsonb, hstore, ltree, btree/gin/gist, enum types, nested record types... the list goes on and on. PG is _very_ hard to beat. Mongodb certainly isn't doing it. Their entire value proposition boils down to create table docs ( doc jsonb );

nyrikki 2y ago

Document-oriented databases are a subclass of the key-value store. 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.

petcat 2y ago
> Postgres jason types are blobs in an RDBMS, and jsonb is to be avoided in almost all cases. 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/functions-json.html
- nyrikki 2y ago
  Fighting with autocorrect, 'json' type is a blob with a path search in front. https://www.postgresql.org/docs/current/datatype-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.
  - petcat 2y ago
    > Concurrency is far more nuanced in MongoDB and storage of documents has far fewer side effects than jsonb. 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.
    - nyrikki 2y ago
      Document updates are atomic, with replica sets. Reads will be eventually consistent. 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.
      - petcat 2y ago
        > The book 'Software Architecture: The Hard Parts' is probably a path forward for you, but any books on modern data architecture would be. 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...
simonw 2y ago
"jsonb is to be avoided in almost all cases" Why's that?
DemocracyFTW2 2y ago
A key/value store is easy to build in Postgres, just define a table with a key column and a value column, that's it. Given that both key and value can be of datatype JsonB or BLOB, there's no restriction in generality, just, you know, aptness for the purpose. Now if you do that, you can—in Postgres—define additional structure or choose a different model entirely if your KV store turns out to be less ideal for whatever you want to do. MongoDB does not give you that choice.

bdjsiqoocwk 2y ago

Postgres is 100% relational AND supports JSON.