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

201–210 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#201

Post by wlll »

benterix wrote: post #193
wlll wrote: post #186

Earlier quoted context omitted.

I was also a bit confused by that part. What is it about Postgres that prevents rapid prototyping? It's not like the schema is set in stone, or even particularly hard to change once you've created it.

Well, yes and no. If you already have your database running in production with many transactions and live connections 24/7, changes to the schema might not be hard per se but always needs careful planning and execution. Additionally, in Postgres a change like adding a column locks the whole table (although I hear this is going to change) so writes are off for a short time. If this becomes unacceptable, you go for a b…

True enough, and the solutions for lighter-weight schema changes have evolved and weren't always so good, but early stage startups often don't really have the sort of data-weight issues that make this hard, unless they're starting with large data sets already. Even at the scale of small hundreds of millions of rows per table (like the company I'm in charge of the database for) it's not much of an issue.

I had to look it up, apparently adding a column with a non-null default was "fixed" in PG 11 (2018), but with a null default it had been fast for a while:

https://www.depesz.com/2018/04/04/waiting-for-postgresql-11-...

Re: The Great Migration from MongoDB to PostgreSQL

#202

Post by 999900000999 »

forgotmyinfo wrote: post #181
999900000999 wrote: post #174

Earlier quoted context omitted.

>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. Looks like the tool did a great job while they were getting started. Mongo is very easy to hack something together with,…

Nonsense. Choosing the correct database isn't "premature optimization", it's the bare minimum of being a competent programmer. Why do we never have time to do it right, but we always have time to do it over?

It's generally faster to get started with Mongo.

If you're talking about a startup, you might not even get to the let's do it over stage. You might have six months to just hack something out so you can raise more funding, and in that case Mongo is a great choice.

The needs of your business might also just evolve over time.

Re: The Great Migration from MongoDB to PostgreSQL

#203

Post by bradleyjg »

darby_eight wrote: post #171
thiht wrote: post #56

Earlier quoted context omitted.

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.

> There's very few legitimate use cases for not using a RDBMS as a main data store I don't think that's true—all the old cases that were legitimate before are still legitimate. The price of both persistent storage and memory has simply come way down to the point where many computational workloads are viable under vertically scalable databases again. I suspect the pendulum will swing the other way one day yet again (a…

In addition to changes in ephemeral and persistent memory, the other big difference between now and nosql’s heyday is improvements in distributed relational transactional databases (newsql).

We haven’t exactly circled the square on CAP but we’ve certainly bent it.

Re: The Great Migration from MongoDB to PostgreSQL

#204

Post by taffer »

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.

As a counterexample, Azure Cosmos or Amazon DynamoDb are marketed as specific solutions for specific problems. Other RDBMS like SqlServer or Postgres are marketed as general purpose solutions because they are in fact general purpose solutions. Mongodb, on the other hand, is a specialized "document database" marketed as a replacement for relational databases.

Re: The Great Migration from MongoDB to PostgreSQL

#205

Post by vbezhenar »

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.

I still didn't have a single use-case to use JSON columns yet. Sometimes I feel that JSON columns are made for people who don't want to properly design their domain model. Big mistake.

Re: The Great Migration from MongoDB to PostgreSQL

#206

Post by liquidgecka »

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…

In 2010-2011 time frame the mongo team sponsored an effort inside of Twitter to replace MySQL with mongo. There was a group of us that worked to migrate the tweet store to Cassandra that were able to talk with leadership and get that initiative killed. Turns out migrating HIGHLY structured data into mongo was never a good idea, especially at that scale.

Re: The Great Migration from MongoDB to PostgreSQL

#207

Post by forgotmyinfo »

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.

Huh, I didn't realize database performance correlates so strongly with stock price. Are there Prometheus metrics for this?

Re: The Great Migration from MongoDB to PostgreSQL

#208

Post by winrid »

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

Re: The Great Migration from MongoDB to PostgreSQL

#209

Post by winrid »

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 answered here: https://news.ycombinator.com/item?id=39865835

Re: The Great Migration from MongoDB to PostgreSQL

#210

Post by jpalomaki »

antfarm wrote: post #161

I remember well how in the early 2000s everybody wanted to get away from their relational systems and NoSQL (Not only SQL) databases were the latest fashion. Looks like we have come full cycle.

Relational databases have also evolved. With JSON types you can now easily mix relations and documents.
Post reply on HN