Ask HN: Do you still use MongoDB?

Post by aabbcc1241 » Fri, May 22, 2020, 6:32 PM UTC

subhobroto wrote: post #199

smoe wrote: post #192

Earlier quoted context omitted.

Thing is, for the early stage development or prototyping, where JSON to SQL is most praised for, to be completely honest, I don't write good migrations either. I change the application code, trigger the cli to generate the sql migration and be done with it. In 99% of cases I don't even look at the generate file, I don't write specific migration tests, etc. If migration runs without error and the application tests pas…

> I much rather build upon the relative robustness and consistency of the sql I got so far, than JSON that is all over the place. Yup. > almost every time I made a JSON column in Postgres for the sake of saving time in the past, it slowed me down almost immediately after adding it Backs my experience fixing software from companies that had terrible data loss issues after these JSON hacks reared their ugly head. I am…

Post by RyanGoosling » Fri, May 22, 2020, 6:40 PM UTC

Post by marcus_holmes » Fri, May 22, 2020, 7:52 PM UTC

subhobroto wrote: post #171

marcus_holmes wrote: post #153

Earlier quoted context omitted.

This is not true. I'm using it because the cost of changing the schema for a feature that may only be experimental is too high. I started off changing the schema every time, and it just got too expensive. Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing. Writing solid migrations can end up being more complex t…

> This is not true. Everything or certain parts of it? > Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing. Sure, you're experimenting and things are in a state of flux. I get it. Been there done that, but not in production. Your customers want features over reliability. This is perfectly OK at a startup - the…

Post by subhobroto » Fri, May 22, 2020, 8:01 PM UTC

marcus_holmes wrote: post #205

subhobroto wrote: post #171

Earlier quoted context omitted.

> This is not true. Everything or certain parts of it? > Using the JSON-to-SQL workflow, I can mess around with feature design and iterate fast, and then crystallise the schema into SQL once it has stopped changing. Sure, you're experimenting and things are in a state of flux. I get it. Been there done that, but not in production. Your customers want features over reliability. This is perfectly OK at a startup - the…

Sorry, I can't wade through that much bullshit. I got about halfway through a carefully-written refutation of everything you wrote, but you're not going to listen to me (since you didn't the first time either). I know what I'm doing. I've been doing this for literally decades. Please stop assuming that people who don't agree with you are doing so from ignorance.

Post by ncmncm » Fri, May 22, 2020, 8:05 PM UTC

ken wrote: post #150

randtrain34 wrote: post #73

All of these replies are for Mongo's product 5+ years ago. MongoDB has changed A LOT since then. Has anyone used MongoDB IN THE PAST 2 YEARS ?

I think the saying goes: fool me once, shame on you; fool me for like 7 or 8 years in a row, shame on me. At this point, if MongoDB could turn on a dime from being an unreliable system to a robust one, that would be the most remarkable part of this story, because I've never seen that happen with any engineering organization. It's rare that engineering departments can significantly improve their quality culture, and i…