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

101–110 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#101

Post by dangtony98 »

smt88 wrote: post #4
vmatsiiako wrote: post #3

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'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, especially in the earlier stages of a company; we can reduce costs and perform various optimizations in the future but what stays at the foundation is whether or not there is strong product market fit such that more customers keep coming in and coming back to use the underlying product — I would say MongoDB's current growth trajectory is in line with that.

I'm hopeful overall that they can turn profitable (maybe not this year or next but eventually so).

Re: The Great Migration from MongoDB to PostgreSQL

#102

Post by bradleyjg »

thiht wrote: post #56
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 not hype though. There's very few legitimate use cases for not using a RDBMS as a main data store, and Postgres happens to be the most popular nowadays, for good reasons.

The number one reason being that it’s free. In a purely technical comparison it is not at the top of the list.

Re: The Great Migration from MongoDB to PostgreSQL

#103

Post by unmole »

Beefin wrote: post #86
jpgvm wrote: post #45

I have done this migration twice and rethinkdb to PostgreSQL once. At this point I think document DBs are as good as dead for new projects. They will live for a really long time still but are in contraction and rent seeking mode now. Expect MongoDB licensing and hosting to increase in price and languish in terms of feature development from here on out.

mongodb is a fortune 100 company and blows through expectations every quarter. doc dbs are far from dead.

> mongodb is a fortune 100 company

Excuse me? MongoDB Inc. posted a mere $1.68 billion in revenue (with a $177 million loss). Coco-Cola posted $45 billion in revenue and ranks at #100. Forget Fortune 100, MongoDb isn't even in the reckoning for Fortune 500.

Re: The Great Migration from MongoDB to PostgreSQL

#104

Post by [deleted] »

Sesse__ wrote: post #74
tomnipotent wrote: post #70

Earlier quoted context omitted.

Postgres as we know it has only existed for about a decade, since the post-9.x era in 2010-2014 when many of its lauded features were added. Replication, heap-only tuples, extensions, foreign data wrappers, JSON, leveraging multiple indexes, parallel index scans, reindex concurrently, JIT compilation, declarative partitioning, stored procedures, and major WAL improvements are all "recent". I love Postgres and it's be…

Extensions and stored procedures are not; they've been around for longer. I do not actually use any of the others you listed (well, occasionally bitmap index scans, but it's not a killer). The main difference between 8.x and 15.x for me is the small stream of optimizer features and tweaks (e.g. at some point, it started being able to reorder outer joins).

[deleted]

Re: The Great Migration from MongoDB to PostgreSQL

#105

Post by oldsecondhand »

thiht wrote: post #56
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 not hype though. There's very few legitimate use cases for not using a RDBMS as a main data store, and Postgres happens to be the most popular nowadays, for good reasons.

In my experience MySql is more popular. Worked at several companies that used MySql, none that used Postgres.

Kids at universities still use XAMMP to learn databases.

Re: The Great Migration from MongoDB to PostgreSQL

#106

Post by lysecret »

kqr wrote: post #69
cpursley wrote: post #60

The one unsolicited piece of tech advice I always give is “Just use Postgres”. Postgres Is Enough: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... There’s some Mongo/json alternatives in the list if you really need unstructured data. And there’s a huge plug-in ecosystem as well for just about anything you could imagine.

But isn't there a point before which "just use sqlite" is more appropriate advice?

I love sqlite as much as the next guy but as soon as you are working with multiple write processes (which you quickly will) you will have to move off. So, why not just start with Postgres?

Re: The Great Migration from MongoDB to PostgreSQL

#107

Post by [deleted] »

Sesse__ wrote: post #74
tomnipotent wrote: post #70

Earlier quoted context omitted.

Postgres as we know it has only existed for about a decade, since the post-9.x era in 2010-2014 when many of its lauded features were added. Replication, heap-only tuples, extensions, foreign data wrappers, JSON, leveraging multiple indexes, parallel index scans, reindex concurrently, JIT compilation, declarative partitioning, stored procedures, and major WAL improvements are all "recent". I love Postgres and it's be…

Extensions and stored procedures are not; they've been around for longer. I do not actually use any of the others you listed (well, occasionally bitmap index scans, but it's not a killer). The main difference between 8.x and 15.x for me is the small stream of optimizer features and tweaks (e.g. at some point, it started being able to reorder outer joins).

[deleted]

Re: The Great Migration from MongoDB to PostgreSQL

#108

Post by dpcx »

iambateman wrote: post #65

I use MySQL for everything - always have. Can someone hit me with a few reasons why you would use Postgres over MySQL? I don’t have any familial affinity to any database, but I’m not sure what the benefits to Postgres are relative to MySQL.

I'll give you the one that matters to me: in MySQL, you can't do DDL statements (create table, alter table, etc) inside a transaction. MySQL will implicitly commit after each DDL statement.

Re: The Great Migration from MongoDB to PostgreSQL

#109

Post by dangtony98 »

namaria wrote: post #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…

The nature of the use-case evolved and, at one point, the MongoDB + Mongoose ORM combination was in fact optimal judging from various aspects including tooling familiarity with most to the primary use-case being the managed cloud service. As the situation evolved, it no longer became optimal and was superseded by various stack-wide adjustments.

Regarding tooling familiarity: In the earlier stages of a company, I'd argue it to be important to pick what you can ship with fastest. You don't want to prematurely, for example, setup a complex microservices setup and deployment with K8s for an idea that is in its infancy and that might not even get that much traffic to begin with. Instead, deploying a monolothic app to Heroku might be the optimal choice (YC has a more extreme term for this they call "duct tape engineering"). As the company grows and there is clearer product market fit, it makes sense to further optimize the stack and perform adjustments as needed.

Regarding the use-case changing, it wasn't entirely obvious in the beginning that a lot of users would self-host the product, so it was designed more-so with the cloud product / managed service in mind; in hindsight things seem more obvious but not in the moment. As it became clearer that more and more people were going to self-host this product, the team shipped more features to accommodate for a simpler self-hosting experience and, as part of that, the PostgreSQL migration.

Re: The Great Migration from MongoDB to PostgreSQL

#110

Post by __s »

kqr wrote: post #69
cpursley wrote: post #60

The one unsolicited piece of tech advice I always give is “Just use Postgres”. Postgres Is Enough: https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f... There’s some Mongo/json alternatives in the list if you really need unstructured data. And there’s a huge plug-in ecosystem as well for just about anything you could imagine.

But isn't there a point before which "just use sqlite" is more appropriate advice?

sqlite is great for what it is

But I recently ended up using sqlite on a site, & it's clear it makes a lot of trade offs to keep itself minimalist. I wish I had just used postgres

That minimalism can be appropriate if you want something that works with a single file to track state & no external process

Post reply on HN