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.
[deleted]
The Great Migration from MongoDB to PostgreSQL
231–240 of 339 posts
Re: The Great Migration from MongoDB to PostgreSQL
#232Friends don't let friends use MongoDB. In my previous job, I got a big promotion in part for getting rid of MongoDB and virtually eliminating our database problems.
[deleted]
Re: The Great Migration from MongoDB to PostgreSQL
#233I don't doubt there are real benefits for them to switch but BTW this is not true: > Difficulty configuring database transactions: With MongoDB, setting up transactions was not trivial because it required running MongoDB in cluster mode with various configuration overhead; this made it extremely difficult, for instance, for customers to run a simple POC of Infisical because it required a production setup of MongoDB.…
[deleted]
Re: The Great Migration from MongoDB to PostgreSQL
#234> With MongoDB, we lost out on many nice features from the relational world ... > ... this hurt in particular because our data was very much relational. That is my best attempt at the summary. The write-up is good, but after you've been around a long (long) time ... you know what this is likely going to involve. Glad relational SQL is still going strong 50 years later.
[deleted]
Re: The Great Migration from MongoDB to PostgreSQL
#235Did anyone here ever see a migration _from_ PostgreSQL/MySQL _to_ MongoDB? I've only ever seen startups pick Mongo, then regret it a few months or years down the line and migrate to a relational database. Did anyone ever see the opposite?
No, but I am currently in a startup that mainly uses DyanomoDB (similar to Mongo) with support from Elastic for more search-based queries. We've found DyanmoDB to be great and we don't feel hindered by the lack of relational-ness.
I will say in case anyone doesn't understand how this might be possible, relational querying is possible in document databases, but they essentially require just different ideas to achieve. In Dynamo, you might need to create secondary indices for example.
Personally I love Postgres and would not mind if we had gone that direction but the more I use DynamoDB the less I feel like Postgres is the "only way"
Re: The Great Migration from MongoDB to PostgreSQL
#236Earlier quoted context omitted.
I didn't even know about that; I checked his Twitter, and first thing is a reply to the Baltimore bridge collapse: > Doors and wheels fall off airplanes. Hundreds of illegal immigrants assault and overrun border guards in Texas. We can’t even muster support for our allies in the security council. But at least our pronouns are in order. https://twitter.com/unclebobmartin/status/177262869295654553... You really need to…
From the other side, people like me, see your odd dismissive behaviour in the same light. This bridge and hundreds of other things going wrong throughout the world atm are all symptoms of some sort of rotten problem, and I honestly don't know why you guys are so adamant about dismissing it. Almost as if you want to see it all come crashing down. Pure evil, as Trump would call it.
Yes, a single accident of the type that's been happing sine bridges were invented, pronouns, and unconditional support for an out of control government in Israel are all deeply related...
Or he's a hyper-politicized idiot completely consumed and obsessed by some topics and needs to talk about them all the fucking time at the drop of a hat, whether appropriate or not.
It has nothing to do with "sides"; it has to do with the forceful injection of completely unrelated matters.
Re: The Great Migration from MongoDB to PostgreSQL
#237What is the point of using a query builder if you’re only going to support a single RDBMS? Why not write straight SQL and avoid the unnecessary abstraction layer? Is the query builder really going to be easier to learn to use (particularly for non-trivial queries) than SQL?
If your DB schema is expressed as an object/class it means your IDE will have robust autocompletion. It’s just a convenience to avoid having to look up the schema for whatever tables you’re interacting with. It helps cut down on trivial bugs during the writing phase, before you even get to testing.
Re: The Great Migration from MongoDB to PostgreSQL
#238I 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.
Maybe you’re just experiencing the trough of disillusionment, from the Gartner curve? I think it’s fair to call document databases a mature technology now, rather than “dead”.
If your normal DB can handle documents like a doc focused DB but better, than it might no longer be worth it to have it as a category but as a feature
Re: The Great Migration from MongoDB to PostgreSQL
#239Earlier quoted context omitted.
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...
Yes but that simplified write complexity means you are pushing a ton of read complexity out to your application.
Re: The Great Migration from MongoDB to PostgreSQL
#240Earlier quoted context omitted.
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)
Looking over it, I don't see why you'd use a managed sqlite service. Unless you started with sqlite & now you're stuck with its quirks
Don't know, I lean pretty minimalist on things, like I'm using `hyper` directly on another website I work on, rather than picking axum or warp