Earlier quoted context omitted.
Sure, but that’s not related to what you said prior. Again, right tool for the job.
Sure. I meant grow in number of ways you use your data, not in volume of data.
What you meant was understood and my point stands
The Great Migration from MongoDB to PostgreSQL
131–140 of 339 posts
Re: The Great Migration from MongoDB to PostgreSQL
#132At some point during the past 10 years or so, the world realized that document databases are actually a bad idea, and relational databases can do the same job better with just a few easy-to-implement QoL improvements (such as JSON operators in SQL). Meanwhile MongoDB's creators thought this was a great time to make Mongo non-free software, presumably with the goal of making a quick buck from cloud operators. The resu…
Document databases aren't an inherently bad idea. They have their uses. I'm using mongodb because it fits my use case: the app is very front-end oriented, and the data the user needs on a specific page fits neatly in one document. There are (quite a lot) related documents, but they are only needed in specific parts of the app, and that's when those are retrieved. Pretty simple. I could argue that in-server SQLite is…
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?
Re: The Great Migration from MongoDB to PostgreSQL
#133Re: The Great Migration from MongoDB to PostgreSQL
#134Earlier quoted context omitted.
What's top of the list technically?
Oracle
Oracle is a giant mess, is the sense I got from trying to work with it in the past.
While I am loathe to recommend any Microsoft product, SQL Server is at least coherent, and has actual transactions like Oracle (and not just "checkpoints")
Re: The Great Migration from MongoDB to PostgreSQL
#135Could have told most people this back when everyone was going to NoSQL.
"You'll be back". Relational capability is just too useful beyond a certain point
Re: The Great Migration from MongoDB to PostgreSQL
#136Ah, 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…
If mongo is just a document database, there's really no reason to use it over elastic. The query story is slightly nicer with mongo, but we're not doing relational algebra here, right? Elastic crushes mongo at literally everything else.
i guess elastic is more heavy setup for some POC.
Re: The Great Migration from MongoDB to PostgreSQL
#137Earlier quoted context omitted.
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.
You haven't missed much TBH. I think the only case where you'd use it in new projects in DynamoDB if you work with AWS.
Dynamo is not mongo?
Re: The Great Migration from MongoDB to PostgreSQL
#138The irony of it all is that MongoDB actually matured and you do not have to jump through hoops to have, say, transactions. I am ALL for Postgres, I even wrote a post about the importance of being fluent in relational databases: https://renegadeotter.com/2023/11/12/your-database-skills-ar... What grinds my gears is the whiplash caused by this frantic stampede from one hype to the next. I am just waiting for the AI hyp…
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.
Re: The Great Migration from MongoDB to PostgreSQL
#139Hoo boy. I did this once. Only it was CouchDB. And they didn’t use any schema. Data had accumulated in it for years. Then a customer said they wanted their data exported to PowerBI.
I used a library that generated a type that could parse any JSON document you threw at it by feeding it examples. So I wrote some tools to scan through the database, generate parse test cases, etc.
I then wrote a library to version and migrate records.
With this I wrote some tools to start extracting meaningful bits out of the big-blob type. I could scan the database, download examples that didn’t work, make test cases, fix those, ask the experts in the system, etc.
Then eventually it started spitting out structured data into Postgres and from there into PowerBI.
Decent article.
Re: The Great Migration from MongoDB to PostgreSQL
#140Earlier 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…
> 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, which achieved its speed by throwing away many safety features, like working transactions and foreign key constraints. Unsurprisingly, when eventually it got an engine that didn't throw caution to the wind, the performance advantage went away.
I spent a lot of time in the early 2000s showing people whose that many of the issues they were facing with their e-commerce websites were ultimately down to the MySQL engine they had picked. But it's faster! Yes it is, but now your application code has to deal with all the things the engine has now offloaded to your application code.
It's not that Postgres' changes were key to increasing market share, but that as MySQL matured, it had no options but to lose its 'advantages'.