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

The Great Migration from MongoDB to PostgreSQL

infisical.com

Post reply on HN
Print view View original

31–40 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#31

Post by sph »

renegade-otter wrote: post #20

The irony of it all is that MongoDB actually matured and you do not have to jump through hoops to have, say, transactions. I am ALL for Postgres, I even wrote a post about the importance of being fluent in relational databases: https://renegadeotter.com/2023/11/12/your-database-skills-ar... What grinds my gears is the whiplash caused by this frantic stampede from one hype to the next. I am just waiting for the AI hyp…

Postgres is no hype, it was already in plateau of productivity when MongoDB came to the web scale scene.

Hadoop just like Mongo had their hyped time in the sun, but RDBMS are far too advanced and versatile than any of them were.

Re: The Great Migration from MongoDB to PostgreSQL

#33

Post by bandrami »

adastral wrote: post #29
radiospiel wrote: post #18

Earlier quoted context omitted.

> The JSON operations are not atomic I hear this today the first time. What exactly os not atomic, and is there a resource with more details?

Not sure if this is what the above comment means by "atomic", but a shortcoming of Postgres' JSON support is that it will have to rewrite an entire JSON object every time a part of it gets updated, no matter how many keys the update really affected. E.g. if I update an integer in a 100MB JSON object, Postgres will write ~100MB (plus WAL, TOAST overhead, etc.), not just a few bytes. I imagine this can be a no-go for c…

It drives me batty to see people store 100MB JSON objects with a predictable internal structure as single records in an RDB rather than destructuring it and storing the fields as a single record. Like, yes, you can design it the worst possible way like that, but why? But I see it all the time.

Re: The Great Migration from MongoDB to PostgreSQL

#34

Post by bandrami »

mulmboy wrote: post #17
winrid wrote: post #15

Earlier quoted context omitted.

The problem is that postgres is not a replacement. The JSON operations are not atomic which is terrible. If you wanna use PG that's cool, but I'd suggest just avoiding JSON.

How are JSON operations not atomic? Genuinely curious

I think the sense is not "atomic by field" or whatever you'd call that. If you're going to ignore the fact that PG is an actual ORDB and just store gigantic blobs of JSON in it, it will write the entire object whenever you update part of it, because the whole point is you're supposed to store it as a multi-field record.

Re: The Great Migration from MongoDB to PostgreSQL

#35

Post by Temporary_31337 »

bandrami wrote: post #33
adastral wrote: post #29

Earlier quoted context omitted.

Not sure if this is what the above comment means by "atomic", but a shortcoming of Postgres' JSON support is that it will have to rewrite an entire JSON object every time a part of it gets updated, no matter how many keys the update really affected. E.g. if I update an integer in a 100MB JSON object, Postgres will write ~100MB (plus WAL, TOAST overhead, etc.), not just a few bytes. I imagine this can be a no-go for c…

It drives me batty to see people store 100MB JSON objects with a predictable internal structure as single records in an RDB rather than destructuring it and storing the fields as a single record. Like, yes, you can design it the worst possible way like that, but why? But I see it all the time .

Because schemas. The whole point of nosql is that you can alter your data model without having to reload the whole database

Re: The Great Migration from MongoDB to PostgreSQL

#36

Post by renegade-otter »

sph wrote: post #31
renegade-otter wrote: post #20

The irony of it all is that MongoDB actually matured and you do not have to jump through hoops to have, say, transactions. I am ALL for Postgres, I even wrote a post about the importance of being fluent in relational databases: https://renegadeotter.com/2023/11/12/your-database-skills-ar... What grinds my gears is the whiplash caused by this frantic stampede from one hype to the next. I am just waiting for the AI hyp…

Postgres is no hype, it was already in plateau of productivity when MongoDB came to the web scale scene. Hadoop just like Mongo had their hyped time in the sun, but RDBMS are far too advanced and versatile than any of them were.

I am not calling Postgres hype - it should have never been NOT hype. It's a reasonable default for most problems,

Now all I read about is how Postgres is awesome, as if it's this great new thing. I guess that makes sense, as the new generation of engineers is rediscovering stable, reliable, lean technologies after a decade of excesses with "exotic" tech.

For grey beards, it's all very odd. Like, "where have you all been?"

Re: The Great Migration from MongoDB to PostgreSQL

#37

Post by Ozzie_osman »

bsaul wrote: post #21

is it still difficult to create a cluster of pg dbs. either for redundancy or speed ? Last time i advocated for using pg vs mongodb, the person replied that mongodb clustering was super easy.

Read replicas are pretty easy on postgres using replication. That said, you need to be careful about replica lag.

If you want to distribute your writes, that's a little trickier. There are options like Citus and such. But still not natively supported.

Re: The Great Migration from MongoDB to PostgreSQL

#38

Post by onetimeuse92304 »

Ah, the old "I used a wrong product for my problem and now I complain the product is bad because it does not suit my case." defence.

MongoDB is a document database. It is not supposed to be good at relations. Also lacking support with cloud providers and lacking experience with MongoDB is not MongoDB's problem, it is your poor decisionmaking. If you value those things, you should have taken it into account when you were choosing MongoDB in the first place.

Now, I am not a big lover of MongoDB. Some years ago I was forced to use it and I had very low opinion of it as quite immature product. It is still far behind in maturity compared to something like Oracle database or PostreSQL, but in the meantime I learned to appreciate some of the things MongoDB is good at.

I also admit that MongoDB's transactions are a total joke. It should be prominently placed in the documentation that you are using them at your own risk. I don't use MongoDB transactions anymore because there are better ways to architect your application with MongoDB without using transactions.

I like MongoDB for the ease of use when rapidly prototyping things. I like the concept of a no-schema, document database and some of the additional features it provides to deal with the document. I like its reactive java driver which is a breeze to use to construct data pipelines quickly. I like change streams.

In the end, I think it is good to have a selection of tools that are good at doing different things.

It is our responsibility to chose the right tool for the job. If you chose poorly, don't try to fault the tool for it.

Re: The Great Migration from MongoDB to PostgreSQL

#39

Post by bandrami »

Temporary_31337 wrote: post #35
bandrami wrote: post #33

Earlier quoted context omitted.

It drives me batty to see people store 100MB JSON objects with a predictable internal structure as single records in an RDB rather than destructuring it and storing the fields as a single record. Like, yes, you can design it the worst possible way like that, but why? But I see it all the time .

Because schemas. The whole point of nosql is that you can alter your data model without having to reload the whole database

Which is great in the early stages of development, but people actually deploy like this

Re: The Great Migration from MongoDB to PostgreSQL

#40

Post by tgv »

p-e-w wrote: post #2

At some point during the past 10 years or so, the world realized that document databases are actually a bad idea, and relational databases can do the same job better with just a few easy-to-implement QoL improvements (such as JSON operators in SQL). Meanwhile MongoDB's creators thought this was a great time to make Mongo non-free software, presumably with the goal of making a quick buck from cloud operators. The resu…

Document databases aren't an inherently bad idea. They have their uses. I'm using mongodb because it fits my use case: the app is very front-end oriented, and the data the user needs on a specific page fits neatly in one document. There are (quite a lot) related documents, but they are only needed in specific parts of the app, and that's when those are retrieved. Pretty simple.

I could argue that in-server SQLite is a bad idea: if you ever need to share the database or distribute tasks, you're fucked. But for some use cases it just works.

"The world" hasn't realized shit. It jumps from fad to fad, fueled by hyped promises and lack of experience.

Post reply on HN