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

191–200 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#191

Post by wlll »

circusfly wrote: post #138
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.

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 far smoother path to performance than with MySQL. It has better tooling, better features, better metadata. "

Right now I would not choose MySQL over Postgres at all, ever. I can't think of a single way it is materially better.

Re: The Great Migration from MongoDB to PostgreSQL

#192

Post by teaearlgraycold »

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…

> I like MongoDB for the ease of use when rapidly prototyping things.

I think this is similar to when people say writing tests speed them up through TDD, then others don’t write any tests at all. What I take away is you can do it either way as long as you’re bought in and are familiar with the process.

For me it’s no trouble at all to define my schema in advanced. And Postgres provides me with the json column escape hatch. Combined with the massive benefit of the data validity guarantees later in the app’s lifecycle I pick Postgres every time.

Re: The Great Migration from MongoDB to PostgreSQL

#193

Post by benterix »

wlll wrote: post #186
forgotmyinfo wrote: post #180

Earlier quoted context omitted.

Sorry, 100 times out of 100, "rapid prototyping" means "we built this with the wrong database, now we're stuck with it". If it isn't obvious how to store your data up front, then you either aren't planning your software well, or you don't actually know what you're building.

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 blue/green deployment which has its own gotchas.

So, while I agree with your main point - there is nothing in Postgres that prevents rapid prototyping, and I would chose it over Mongo any moment, I understand why some people might prefer the more "dirty" approach.

Re: The Great Migration from MongoDB to PostgreSQL

#194

Post by tristan957 »

__s wrote: post #110
kqr wrote: post #69

Earlier quoted context omitted.

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

Have you tried using something like Turso? Curious how that experience would be for you.

(I do not work at Turso)

Re: The Great Migration from MongoDB to PostgreSQL

#195

Post by bashinator »

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

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…

I believe one of the job interview problems at Mongo for software engineers, was to design a relational layer on top of the document store.

Re: The Great Migration from MongoDB to PostgreSQL

#196

Post by taffer »

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…

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.

Re: The Great Migration from MongoDB to PostgreSQL

#197

Post by tomnipotent »

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

Postgres 8 supported functions capable of returning tuples (RETURN QUERY), but lacked transaction control and other features that CREATE PROCEDURE added in Postgres 11 (2018).

Extensions in Postgres 8 (and earlier) were also half-baked compared to 9.1 (2011), which added CREATE EXTENSION and other quality-of-life improvements including standardization.

The latest complete implementations are what most people have in mind when talking about them.

Re: The Great Migration from MongoDB to PostgreSQL

#198

Post by joneholland »

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

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.

Re: The Great Migration from MongoDB to PostgreSQL

#199

Post by forgotmyinfo »

trynumber9 wrote: post #167
Dudelander wrote: post #165

Earlier quoted context omitted.

A fad that set back the industry by a decade.

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?
Post reply on HN