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

151–160 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#151

Post by zzzeek »

onetimeuse92304 wrote: post #55
thih9 wrote: post #41

Earlier quoted context omitted.

To be fair, Mongodb’s pr team did their best to present it as the solution to all problems. > In 2012, 10gen’s VP of Corporate Strategy Matt Asay argued “there will remain a relatively small sphere of applications unsuitable for MongoDB … the majority of application software that developers write will be in use cases that are better fits for MongoDB and other NoSQL technology … Those functions that really help a comp…

To be fair, almost all product PR teams do the same. I just ignore most of what they say in favour of my own opinion that I try to build based on reading actual technical documentation, experimenting with the product, etc. Anybody who makes tech decisions based solely on what PR teams say is naive and incompetent at best.

MongoDB came into the community like a ton of bricks, taking over conferences, flooding the zone with mugs and t shirts, and for a time there, you couldn't view the front page of hacker news without at least two MongoDB posts. The death of SQL, now known to be an inferior relic of the past, was a regular topic of discussion. There's a reason why the "Web Scale" meme is so famous, because that's what actually happened for awhile there. SQL was an inferior, leaky abstraction, and ACID was not "web scale". it became all about the CAP theorem (which I hardly ever see anyone writing about these days).

only a year or two later, when teams that went all in on MongoDB at the behest of MongoDB's marketing department started realizing they'd been sold a bill of goods, did the slow and arduous march back to what continued to be the best generalized solution for 95% of data problems, the ACID compliant relational database, begin to occur. given that, this blog post seems really behind the times.

Re: The Great Migration from MongoDB to PostgreSQL

#153

Post by LtWorf »

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

Excited, vocal users make the most noise. Somehow the entire Mongo DB era passed me through and I never used it once. I used to use MySQL in the 2000s, and switched to PostgreSQL in the 2010s.

They used it at my 1st job, a startup.

They had an ORM which made everything much slower, and the most common operation they did was to add items into lists, which causes the whole document to be resized and requires it to be moved.

It could have been done with 1 sql server, but we needed 4 really heavy mongodb servers instead. And of course our code was buggy so the schema was all over the place.

Re: The Great Migration from MongoDB to PostgreSQL

#154

Post by kstrauser »

hibikir wrote: post #140
benterix wrote: post #127

Earlier quoted context omitted.

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

I used postgres in the 90s. The biggest complaint was that postgres's default config needed a change so you could connect to it remotely, as the default, wisely at the time, decided that allowing connections from any IP by default before you changed any security setting whatsoever was a real problem. The MySQL performance advantages were large, with the small caveat that it was fast as long as you were using MyISAM,…

That mirrors my experience. MySQL was faster for use cases where data loss was acceptable. Will anyone die if you lose some web log analysis stats? Probably not. You wouldn’t want to use it for anything where guaranteed consistency was critical, like anything involving money, but it was an alright replacement for things like an in-memory data store.

I say “was”. I hear it’s vastly better now.

Re: The Great Migration from MongoDB to PostgreSQL

#155

Post by gkbrk »

kstrauser wrote: post #154
hibikir wrote: post #140

Earlier quoted context omitted.

I used postgres in the 90s. The biggest complaint was that postgres's default config needed a change so you could connect to it remotely, as the default, wisely at the time, decided that allowing connections from any IP by default before you changed any security setting whatsoever was a real problem. The MySQL performance advantages were large, with the small caveat that it was fast as long as you were using MyISAM,…

That mirrors my experience. MySQL was faster for use cases where data loss was acceptable. Will anyone die if you lose some web log analysis stats? Probably not. You wouldn’t want to use it for anything where guaranteed consistency was critical, like anything involving money, but it was an alright replacement for things like an in-memory data store. I say “was”. I hear it’s vastly better now.

If you want a fast DB for web log analysis, you shouldn't look at MySQL or PostgreSQL anyway. ClickHouse will run circles around both of them for the use case of web log analysis.

Re: The Great Migration from MongoDB to PostgreSQL

#156

Post by gwbas1c »

thih9 wrote: post #41
onetimeuse92304 wrote: post #38

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

To be fair, Mongodb’s pr team did their best to present it as the solution to all problems. > In 2012, 10gen’s VP of Corporate Strategy Matt Asay argued “there will remain a relatively small sphere of applications unsuitable for MongoDB … the majority of application software that developers write will be in use cases that are better fits for MongoDB and other NoSQL technology … Those functions that really help a comp…

They were doing that back in 2010. I went to a few conferences where they promoted MongoDB as an all-purpose database that was the "next thing" compared to SQL.

Once everyone realized its shortcomings as a general-purpose database, there was a gradual "oh shit this isn't working" migration back to SQL-based databases.

I think the big problem is that the MongoDB programming model and APIs are very nice; we really need a database that is still relational "under the hood" but has an API that's more like MongoDB.

Re: The Great Migration from MongoDB to PostgreSQL

#157

Post by onetimeuse92304 »

thih9 wrote: post #148
onetimeuse92304 wrote: post #55

Earlier quoted context omitted.

To be fair, almost all product PR teams do the same. I just ignore most of what they say in favour of my own opinion that I try to build based on reading actual technical documentation, experimenting with the product, etc. Anybody who makes tech decisions based solely on what PR teams say is naive and incompetent at best.

> To be fair, almost all product PR teams do the same. No, mongodb’s PR approach and results were largely uncommon at the time. They didn’t advertise directly but instead targeted and amplified dev communities - as detailed in the article linked earlier. The result was that people not associated with mongodb talked about mongodb at various dev conferences and in blog posts. People didn’t want to listen to PR teams th…

Again, I will stick to saying that if you use technology you have no experience with, the problems resulting from it are on you.

Testing out technology on important projects is reckless and is a risk a lot of people take but push away any responsibility for.

As a professional, before I suggest to use a technology at a project, at first at the very minimum I spend some time with it to learn the ins and outs. Every technology has cons. Just because you don't know them does not absolve you from responsibility for them.

The reality is that most applications are boringly similar once you define the problem in simple words. There is very rarely a need to use new technology. It is my experience that it is usually better to use technology that is not necessarily cutting edge but one that you know well and that you can easily hire people who know it well.

Because no technology is perfect, but it is much better to know the cons ahead of time and know you will have people who will know the problems and who can find reasonable solutions for.

I am personally sick and tired of people who first advocate for new technology to be added to the project, touting its supposed benefits, not knowing the cons, then don't want to take responsibility once we actually find the dead bodies.

Re: The Great Migration from MongoDB to PostgreSQL

#158

Post by jerf »

tkellogg wrote: post #141
finaard wrote: post #129

Earlier quoted context omitted.

To me the article read more that PostgreSQL might have been the better choice from the beginning - but due to lack of experience in the team MongoDB was "good enough" at that point.

I recall when my team chose MongoDB ~2011, Postgres & friends didn't have JSON columns, so there was a lot of extra data modelling that probably was unnecessary. The biggest use case for MongoDB was for huMongous data. Obvs MongoDB was a good fit, because of the name.

Yes, I think it's reasonable to say the NoSQL community drove the JSON columns in the relational databases. And while the JSON-ness of said columns is not necessarily the relevant bit to me, having the escape hatch of being able to just sort of splat out a "other" column has been something I've used several times, and it has relieved some non-trivial stress and strain in relational designs in my opinion. It's not even that hard to migrate something out of the JSON column if you want to raise it to a full column later, and JSON indices mean you may not even really need to.

I have a hard time justifying a document database in 2024 when I have 2024 Postgres; I don't know how large the window is where MongoDB will do something Postgres won't, but I know my systems are not in that window. (Assuming it even exists, which I wouldn't be surprised it doesn't, but for the sake of argument I will assume it does.) But a decade ago that would be a much harder decision if I truly had a document-based use case.

Re: The Great Migration from MongoDB to PostgreSQL

#159

Post by kstrauser »

dpcx wrote: post #108
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.

Aww, yes. It’s so nice being able to wrap giant schema and data migrations in a transaction so the whole process is atomic.

Re: The Great Migration from MongoDB to PostgreSQL

#160

Post by throw_m239339 »

onetimeuse92304 wrote: post #38

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

> MongoDB is a document database.

So can PostgreSQL be with JSON types and queries.

Post reply on HN