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

291–300 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#291

Post by evanelias »

mixmastamyk wrote: post #286
bit_flipper wrote: post #255

I've run Postgres at large scale (dozens of machines) at multiple companies. I've also run MongoDB at large scale at multiple companies. I like both generally. I don't really care about data modelling differences - you can build the same applications with approximately the same schema with both if you know what you're doing. I don't understand how folks seemingly ignore Postgres' non-existent out of the box HA and ho…

Citus is open source and well financed. This comment may have made sense a few years ago, but no longer.

By "well financed" you mean "owned by Microsoft"?

That situation raises a separate set of concerns, especially in the context of Microsoft's main database cash cow being SQL Server, not Postgres/Citus.

Re: The Great Migration from MongoDB to PostgreSQL

#292

Post by phamilton »

dvnguyen wrote: post #262
phamilton wrote: post #117

Earlier quoted context omitted.

Some things that are nice in Postgres and missing in MySQL: - Create constraints as NOT VALID and later VALIDATE them. This allows you to create them without expensive locks. - explain (analyze, buffers). I miss this so much. - Row level security. - TOAST simplicity for variable text fields. MySQL has so many caveats around row size and what features are allowed and when. Postgres just simplifies it all. - Rich exten…

How about HA and horizontal scaling? I’ve heard that MySQL excels in that area.

I mostly have used AWS Aurora there, which is significantly better than vanilla MySQL or Postgres and both are similar enough.

In Aurora, Postgres has Aurora Limitless (in preview) which looks pretty fantastic.

As far as running yourself, Postgres actually has some advantages.

Supporting both streaming replication and logical replication is nice. Streaming replication makes large DDL have much less impact on replica lag than logical replication. As an example, if building a large index takes 10 minutes then you will see a 10 minute lag with logical replication since it has to run the same index build job on the replica once finished on the primary. Whereas streaming replication will replicate as the index is built.

Postgres 16 added bidirectional logical replication, which allows very simple multi-writer configurations. Expect more improvements here in the future.

The gap really has closed pretty dramatically between MySQL and Postgres in the past 5 years or so.

Re: The Great Migration from MongoDB to PostgreSQL

#293

Post by synthc »

CuriouslyC wrote: post #287
finikytou wrote: post #136

Earlier quoted context omitted.

i guess elastic is more heavy setup for some POC.

That might have been true in the past but it's not hard to PoC with elastic using docker compose.

Elastic is much more of a pita to maintain and monitor than Mongo

Re: The Great Migration from MongoDB to PostgreSQL

#294

Post by fijiaarone »

Shorel wrote: post #172
arp242 wrote: post #50

Earlier quoted context omitted.

I remember Robert C. Martin ("Uncle Bob") going on about how No-SQL will replace literally all SQL and that there is literally not a single use case for relational data and SQL. I wonder if he ever came back on that. Now, my opinion of Martin in general is not especially high and he's a bit of a controversial figure, but it wasn't just the kids. And Martin is also all about reliable software, so that makes it even mo…

His words: "I am also self-taught. I never got a degree of any kind. I entered the industry at the tender age of 17 and never looked back. Frankly, school isn’t all it’s cracked up to be — especially in the software field." https://twitter.com/unclebobmartin/status/107212575854868889... Which means his opinions are more often than not uninformed opinions and should be taken with a grain of salt.

When you turn 23 in a couple years, you’ll look back at college and realize you weren’t at the apex of all knowledge back then.

Re: The Great Migration from MongoDB to PostgreSQL

#295

Post by fijiaarone »

benterix wrote: post #127
renegade-otter wrote: post #36

Earlier quoted context omitted.

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

> For grey beards, it's all very odd. Like, "where have you all been?" To be frank, PostgreSQL has evolved a lot since the late nineties. There was a time where people preferred MySQL over it at it seemed to work faster, certain things were easier and so on.

PostgreSQL didn’t exist in the 1990s. It was called Ingres. Postgres started as a personal project and was first released in 1999, but was unusable. Around 2004 the project started getting popular and hipsters started screaming that MySQL didn’t have stored procedures and wasn’t fully ACID. Acid became a buzzword for PG fanboys, even though data corruption and memory leaks plagued the system for the first decade. It became a stable around 2008 as long as you didn’t mind restarting your database every few days. PostgreSQL didn’t really become a viable option until around 2010.

Re: The Great Migration from MongoDB to PostgreSQL

#296

Post by mixmastamyk »

evanelias wrote: post #291
mixmastamyk wrote: post #286

Earlier quoted context omitted.

Citus is open source and well financed. This comment may have made sense a few years ago, but no longer.

By "well financed" you mean "owned by Microsoft"? That situation raises a separate set of concerns, especially in the context of Microsoft's main database cash cow being SQL Server, not Postgres/Citus.

I'm as skeptical of MS as anyone. However it is licensed GNU AGPL, so not particularly worried.

Re: The Great Migration from MongoDB to PostgreSQL

#297

Post by smt88 »

dangtony98 wrote: post #101
smt88 wrote: post #4

Earlier quoted context omitted.

They grew 30% if you look at revenue, but that's not how people determine whether a business is healthy. EBITDA is a better metric, and that number was getting dramatically worse every year until 2023. But even in 2023, EBITDA was -$202M. I don't see it ever approaching $0. So it's still a shit business on top of a shit product that no one ever really needed.

I'm actually very bullish on MongoDB. While the article and significant sentiment in threads suggest a push off MongoDB toward PostgreSQL, I do think MongoDB has its own place in the stack and that it won't be obsoleted. I've personally had many pleasant experiences working with it in past projects. Regarding business metrics, I may have a slight bias coming from the startup world but we often value revenue the most,…

HN should be full of Mongo's users and advocates, and yet this site loathes it. That by itself is a sign that it's a zombie.

The reason we don't just look at revenue is that you can "buy" revenue with ads and sales teams. But if that revenue growth costs more than it pays because your customers aren't sticky, then your business doesn't work. You can't apply startup principles to this large, aging public company.

Re: The Great Migration from MongoDB to PostgreSQL

#298

Post by smt88 »

otabdeveloper4 wrote: post #8
smt88 wrote: post #4

Earlier quoted context omitted.

They grew 30% if you look at revenue, but that's not how people determine whether a business is healthy. EBITDA is a better metric, and that number was getting dramatically worse every year until 2023. But even in 2023, EBITDA was -$202M. I don't see it ever approaching $0. So it's still a shit business on top of a shit product that no one ever really needed.

MongoDB is great if what you need is a replicated log or queue. It's what Kafka should have been.

As others have said, you can just use your RDBMS for that now. Mongo is a feature of better products.

Re: The Great Migration from MongoDB to PostgreSQL

#299

Post by winrid »

callalex wrote: post #239
winrid wrote: post #208

Earlier quoted context omitted.

It's not an issue with size. It's an issue with race conditions. With Mongo I can update a.b and a.c concurrently from different nodes and both writes will set the right values. You can't do that with PG JSONB unless you lock the row for reading...

Yes but that simplified write complexity means you are pushing a ton of read complexity out to your application.

What?? That's an insane argument. That's like saying if one client sets column X to 1 and another client concurrently sets SET y = 2, one client's writes will be LOST. It shouldn't, and it doesn't. If it did, nobody would use Postgres. This issue only exists with PG's JSON impl.

Re: The Great Migration from MongoDB to PostgreSQL

#300

Post by callalex »

winrid wrote: post #299
callalex wrote: post #239

Earlier quoted context omitted.

Yes but that simplified write complexity means you are pushing a ton of read complexity out to your application.

What?? That's an insane argument. That's like saying if one client sets column X to 1 and another client concurrently sets SET y = 2, one client's writes will be LOST . It shouldn't, and it doesn't. If it did, nobody would use Postgres. This issue only exists with PG's JSON impl.

What?? That’s an insane way to describe what I’m talking about. Data/transaction isolation is very complex and extremely specific to every use case, which is why database engines worth anything let you describe to them what your needs are. Hence why when one client writes to Y they specify what they think X should be if relevant and get notified to try again if the assumptions are wrong. An advantage of specifying your data and transaction model up front is that it will surface these subtle issues to you before they destructively lose important information in an unrecoverable manner.

https://en.wikipedia.org/wiki/Isolation_(database_systems)

Post reply on HN