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

211–220 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#211

Post by jimbokun »

jerf wrote: post #158
tkellogg wrote: post #141

Earlier quoted context omitted.

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

Horizontal scaling is still challenging in Postgres. That’s where “NoSQL” systems still have their place. Or one of the SQL systems layered on to a NoSQL architecture, with the trade offs that entails.

Re: The Great Migration from MongoDB to PostgreSQL

#212

Post by abound »

vbezhenar wrote: post #205
tkellogg wrote: post #141

Earlier quoted context omitted.

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.

The main use case I find myself reaching for JSON/JSONB fields is unstructured map-like metadata, like KV tags on a resource, where the data model/domain has no expectation that any given field is set.

Re: The Great Migration from MongoDB to PostgreSQL

#213

Post by madsbuch »

J_Shelby_J wrote: post #150
madsbuch wrote: post #111

Earlier quoted context omitted.

I am curious on this. Why do you think SQLite is simpler than Postgres? and in what setting is that the case? Sqlite comes with the headache of managing an attached volume.

Building an mvp or a single container app. I’m actually trying to get Postgres to work like this right now. SQLite being embedded is simpler to use and more performant in this environment as there is no IPC overhead.

Why even use a database? Just assign a variable. All state is dead the second you destroy the container anyways.

Re: The Great Migration from MongoDB to PostgreSQL

#214

Post by jeff-davis »

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…

"It is our responsibility to chose the right tool for the job."

That perspective doesn't work well for database products, in my opinion. There is a huge pressure for databases to evolve with your business and applications and to adapt to whatever your throw at it.

Swapping out a database product is less like changing tools and more like changing a foundation. You can't do it every time a new problem arises.

That's not to say you can't use a few different products if that makes sense. But that has its complications.

Re: The Great Migration from MongoDB to PostgreSQL

#215

Post by eddd-ddde »

tgv wrote: post #166
eddd-ddde wrote: post #132

Earlier quoted context omitted.

What about a Postgres database where you store your documents in a key value table of json objects? What mongodb benefits would you be missing?

What benefit does switching to postgresql bring? When mongodb stops being maintained, I'll consider postgres, but until then, I now only see downsides.

Lot's of useful features?

You can join data when needed, proper transactions, schemas where you need schemas.

For example you start with a basic (key, json) table. Once you begin to stabilise your schema, add columns generated from your json objects, now you can get proper joins, indexes, validations, on said columns.

Re: The Great Migration from MongoDB to PostgreSQL

#216

Post by wlll »

joneholland wrote: post #198
taffer wrote: post #196

Earlier quoted context omitted.

So what is a good use case for Mongodb? I have never seen an application where a "document database" would have been a good choice. In every project where I have seen Mongodb, it has turned out to be the wrong choice. Even for prototyping there are many other good choices since RDBMS like Postgres have implemented JSON support. Mongodb looks like a solution in search of a problem.

Applications that are essentially form wizards are a great fit for a document database. Think application forms etc.

Is there a benefit of Mongo for that over just Postgres with JSONB columns? You're still storing JSON in Postgres but you'd get the relational aspects too for things like users having many forms, billing and account relationships etc.

Re: The Great Migration from MongoDB to PostgreSQL

#217

Post by [deleted] »

kstrauser wrote: post #149
circusfly wrote: post #138

Earlier quoted context omitted.

I've nothing against Postgres but MySQL is a wonderful option that is likely still in far higher and heavier use, when considering open source databases.

In my mind, MySQL no longer exists. It’s a weird Oracle thing that I wouldn’t touch with a lineman’s pole. MariaDB is what happened after MySQL disappeared.

[deleted]

Re: The Great Migration from MongoDB to PostgreSQL

#218

Post by rsanek »

forgotmyinfo wrote: post #199
trynumber9 wrote: post #167

Earlier quoted context omitted.

Not sure on that, it made some of the SQL solutions innovate quite a bit.

What did relational databases need from all the document DBs du jour? Broken transactions? Lack of ACID guarantees? Devil-may-care schemas?

yep, the last one -- Postgres' support for json / jsonb is way better now.

Re: The Great Migration from MongoDB to PostgreSQL

#219

Post by [deleted] »

wlll wrote: post #191
circusfly wrote: post #138

Earlier quoted context omitted.

I've nothing against Postgres but MySQL is a wonderful option that is likely still in far higher and heavier use, when considering open source databases.

I wrote this in another comment, but it's relevant here I think: " I do scaling and performance work, mostly with Rails apps, but a significant amount of the work is database level and not language specific. I've used both postgres and MySQL (and a few other databases) going back to 2000. The best thing I can hear from a company when I start is "We use Postgres". If they're using postgres then I know there's likely a…

[deleted]

Re: The Great Migration from MongoDB to PostgreSQL

#220

Post by unclebucknasty »

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, it burst onto the scene back in the "all you need is NoSQL...RDBMS is dead" era.

So it became one of those software dogma things and I remember having "debates" right here on HN, including around the necessity of transactions.

So it's kind of ironic to see people now chastising those who fell prey to the dogma. Full circle.

Post reply on HN