Live data from Hacker News

The Great Migration from MongoDB to PostgreSQL

infisical.com

61–70 of 339 posts

Re: The Great Migration from MongoDB to PostgreSQL

#61

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…

A JSON object which is 100 MB after compression is a quite huge thing.

Re: The Great Migration from MongoDB to PostgreSQL

#62

Earlier quoted context omitted.

Because schemas. The whole point of nosql is that you can alter your data model without having to reload the whole database

Which is great in the early stages of development, but people actually deploy like this

The benefits of going schemaless in the early stages of development are highly suspect in my experience. The time that one might save in data modeling and migrations comes out from the other end with shittier code that’s harder to reason about.

Re: The Great Migration from MongoDB to PostgreSQL

#63

Earlier quoted context omitted.

Generally with these migrations biggest problem in my experience is that all the operational learnings are not transferrable. You often want to create expertise and achieve operational excellence with the tech that you start out.

Back in the day we used to say "you choose your database once". You can swap in/out a lot of things, but your data store is really the core. It is shockingly hard to change your storage engine once you are serving customers, so you really want to get that right.

Exactly, languages and frameworks come and go - but get the data layer right and you’re set.

Re: The Great Migration from MongoDB to PostgreSQL

#66
post #12

Earlier quoted context omitted.

Why do you choose EBITDA? Last I heard it was utter nonsense”, at least according to Warren Buffet. https://m.youtube.com/watch?v=tvnKylAyLbQ

You'd probably save time if you directly suggest what income metric you want to use. In the video, Buffet is basically saying he cares about income after interest, tax, depreciation and amortisation. In other words, that he cares about actual income. That'd be very on-brand for Buffet. That measure won't be good for MongoDB Inc. either; they've been millions in the red for years. Losing $100 million in a year would b…

so by Buffet's metric, Mongo is doing even worse

Re: The Great Migration from MongoDB to PostgreSQL

#67

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.

Not worrying about Oracle suing you is a good reason to use PostgreSQL or MariaDB.

Re: The Great Migration from MongoDB to PostgreSQL

#68

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.

Back when I selected which database to get more fluent in one of the concerns I had about MySQL is that it was decribed as playing loose and fast with type casts, at least compared to Postgres.

Re: The Great Migration from MongoDB to PostgreSQL

#69

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?

Re: The Great Migration from MongoDB to PostgreSQL

#70
post #31

Earlier quoted context omitted.

Postgres is no hype, it was already in plateau of productivity when MongoDB came to the web scale scene. Hadoop just like Mongo had their hyped time in the sun, but RDBMS are far too advanced and versatile than any of them were.

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…

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 been my go-to default since 2014 and you can pry it from my cold dead hands, but it's more contemporary with Perl 6 than Perl 5 if we're talking grey beards.

Post reply on HN