4 ms·

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

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...

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...