Live data from Hacker News

The Great Migration from MongoDB to PostgreSQL

infisical.com

21–30 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#22
post #11

Earlier quoted context omitted.

Why do you choose EBITDA? Last I heard it was utter nonsense”, at least according to Warren Buffet. https://m.youtube.com/watch?v=tvnKylAyLbQ

Their "Comprehensive Losses" for the last 3 years are (in thousands) (171,150) (343,375) (309,090) So there you go...

they lost 300 million in one year?

Re: The Great Migration from MongoDB to PostgreSQL

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

Mongo absolutely can be the right answer if you need to horizontally scale to tens or hundreds of TBs. Anything below that I’d rather have a small cluster of big Postgres instances. There’s value in a SQL RDBMS which you just don’t get anywhere else.

Re: The Great Migration from MongoDB to PostgreSQL

#24
post #4

Earlier quoted context omitted.

I wouldn't say "Mongo is on life support" – it's actually a very successful business growing 30% YoY on a massive scale. Yet, I agree that the license switch has definitely damaged their long-term ecosystem.

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 was totally expecting someone to come up with some vanity metric here, but a negative EBITDA of several HUNDRED MILLION? Jesus. How did that happen. B2B business should be a symphony of ka-chings for them.

Re: The Great Migration from MongoDB to PostgreSQL

#25
post #5

I don't doubt there are real benefits for them to switch but BTW this is not true: > Difficulty configuring database transactions: With MongoDB, setting up transactions was not trivial because it required running MongoDB in cluster mode with various configuration overhead; this made it extremely difficult, for instance, for customers to run a simple POC of Infisical because it required a production setup of MongoDB.…

Are there any disadvantages to using transactions with a single-instance replica set?

We run a single instance replica set for three years in a small application for its transaction function.

The only difference we noticed is the additional replica set setting for a new instance. No other disadvantages are found.

Re: The Great Migration from MongoDB to PostgreSQL

#26
> As part of that stack, we chose MongoDB + Mongoose ORM because the combination presented least overhead and allowed us to ship quality features quickly. As Sir Tony Hoare states, “premature optimization is the root of all evil,” and there was certainly no need for further optimization at the time.

I find it interesting that one sentence claims they made an optimal choice for feature delivery speed, and the next one that they rationalized it as "non optimal as prescribed by Hoare". Never mind the fact that three sentences down the original quote Hoare said "It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail."

Re: The Great Migration from MongoDB to PostgreSQL

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

Why do you choose EBITDA? Last I heard it was utter nonsense”, at least according to Warren Buffet. https://m.youtube.com/watch?v=tvnKylAyLbQ

People who use EBITDA are either trying to con you or they're conning themselves.

Re: The Great Migration from MongoDB to PostgreSQL

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

> 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 certain use cases.

Re: The Great Migration from MongoDB to PostgreSQL

#30
> Missing out on relational features: With MongoDB, we lost out on many nice features from the relational world like CASCADE which, when specified, deletes all referenced resources across other tables whenever a target resource is deleted; this hurt in particular because our data was very much relational.

I'd be very curious what their data model was in relation to this problem. I wonder if denormalization of the data would have solved the problem without a need for a full database hop.

Post reply on HN