Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB takes a swing at PostgreSQL after claiming wins against rival

theregister.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#41

Post by petcat »

nyrikki wrote: post #35
petcat wrote: post #24

Earlier quoted context omitted.

> 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

Fighting with autocorrect, 'json' type is a blob with a path search in front. 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 a…

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

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#42

Post by dgacmu »

PaulHoule wrote: post #23
wslh wrote: post #20

Earlier quoted context omitted.

Isn't PostgreSQL supporting JSON and queries over them? [1] [1] https://www.reddit.com/r/django/comments/14f68rz/postgresql_...

It does. See https://www.postgresql.org/docs/current/datatype-json.html I think it is ugly as hell to work w/ json documents in pgsql but most of the eng managers I’ve known think you couldn’t get fired for choosing pgsql.

It's ugly but having a field that's just a dictionary is really handy and not too ugly.

We use a lot of them for things like "tags" (which can take freeform user- or ml- supplied image tags in key:value format). I adore it. (We tried mongo with one of our annotation systems and regretted it.) It's a very nice way to balance quick development (you don't need a schema change to try a feature for a while) with the benefits of a mostly schema-defined db.

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#43

Post by nyrikki »

petcat wrote: post #41
nyrikki wrote: post #35

Earlier quoted context omitted.

Fighting with autocorrect, 'json' type is a blob with a path search in front. 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 a…

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

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.

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#44

Post by ta988 »

PaulHoule wrote: post #16
benwilber0 wrote: post #3

I had such a bad experience with Mongo DB back in 2012-2013 that I don't think I'll ever use it again, or even really consider it. But maybe it's changed and gotten better since then? Anyway. I just use Postgres.

If you like the document db idea there are a lot of choices, especially https://arangodb.com/ which I think gets little attention because people who use it see it as a secret weapon. Too bad about the license though. Also https://couchdb.apache.org/ and https://developer.marklogic.com/

Arango isn't comparable, the Free edition is extremely limited. PostreSQL doesn't say how much you are allowed to store or what you can use it for.

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#45

Post by petcat »

nyrikki wrote: post #43
petcat wrote: post #41

Earlier quoted context omitted.

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

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 sca…

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

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#46

Post by evantbyrne »

petcat wrote: post #38
evantbyrne wrote: post #30

Earlier quoted context omitted.

I suspect a good amount of the hype around NoSQL was driven by frontend developers transitioning into backend work via Node, and Mongo being relatively simple to get started on compared to relational databases. And that culture seems to have stuck. To this day, many popular backend js frameworks either completely ignore relational data storage or slap some bare bones interface over it.

I believe that this is also why we're starting to see a surge in people wanting to run SQLite as their backend database. It's similarly simple to start out with, and also similarly flimsy when dealing with actual data integrity. Very limited types, limited isolation options, ref integrity disabled by default (Mongo DB also disables things by default that hurts their benchmarks). But hey, SQLite is better than Mongo D…

There might be some truth in that. I've come to respect SQLite more as a serious database though. It can perform well if you can manage the trade-offs of running on a single server and turn the right knobs. The upgrade path to Postgres is also a lot clearer than with Mongo.

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#47

Post by magicalhippo »

shoo wrote: post #8
petcat wrote: post #4

Earlier quoted context omitted.

/dev/null scales better than all of them

/dev/null : the optimal solution for write-only workloads

It's eventually consistent as well, so same guarantees as MongoDB in that regard.

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#48

Post by jdyer9 »

nahnahno wrote: post #39
codr7 wrote: post #15

I consider MongoDB a huge warning sign; if you think that's a good idea I don't want anything to do with your code.

Mongo is hated here but I’ve made many services with Postgres and mongo is just far easier to use. Json tooling in Postgres is not as good. I don’t particularly hate or like any one database, but thinking about migrating the workloads that I have in mongo to Postgres just gives me no interest. Mongo solves the problems I have very well.

That's the thing about Mongo, it's great until it's not. And Not comes quickly for many projects.

There's probably tons of small Mongo installations all over the internet doing great in their little niche. But the moment a project gets too big for Mongo, it becomes a problem very quickly. I suppose it's like comparing a bike to a car. If your problem is getting around a small town with nice weather, the bike wins. But the moment you need to move 5 people on the interstate to the next town in bad weather, there's no real choice besides the car.

That's been my experience with mongo every time

Re: MongoDB takes a swing at PostgreSQL after claiming wins against rival

#49

Post by DemocracyFTW2 »

For people who don't want to take form participants in this thread, maybe you should consider listening to no other than Mike Stonebraker[1]:

NoSQL databases that store data as JSON documents, such as MongoDB and Couchbase, benefited from developer excitement over a denormalized data structures, a lower-level API, and horizontal scalability at the cost of ACID transactions. However, document stores “are on a collision course with RDBMSs,” the authors write, as they have adopted SQL and relational databases have added horizontal scalability and JSON support.

“Another wave of developers will claim that SQL and the RM are insufficient for emerging application domains,” they write. “People will then propose new query languages and data models to overcome these problems. There is tremendous value in exploring new ideas and concepts for DBMSs (it is where we get new features for SQL). The database research community and marketplace are more robust because of it. However, we do not expect these new data models to supplant the RM.”

[1] https://www.datanami.com/2024/07/08/dont-believe-the-big-dat... discussion: https://news.ycombinator.com/item?id=41406420

Post reply on HN