Live data from Hacker News

Ask HN: Do you still use MongoDB?

news.ycombinator.com

91–100 of 243 posts

Re: Ask HN: Do you still use MongoDB?

#91

Earlier quoted context omitted.

Depends on what. You seem to think this is about tech. It's not. It's about company culture, trust, and reputation. Code can change reasonably fast, in some cases 10 years is enough to replace an entire codebase. But company culture has or can have an expected life time way longer than 10 years. In this case, my heuristic is justified.

Are you not buying iPhones because Apple’s first music player had no wireless and less space than the Nomad? (For the younger people https://slashdot.org/story/01/10/23/1816257/apple-releases-i... )

How much memory a device has now does not depend on company culture. How reliable we can expect a future feature to be, does.

I think you're making an active effort to misunderstand me.

Re: Ask HN: Do you still use MongoDB?

#92
post #88
post #74

Yes. If we were going to start from scratch today, we'd probably use Postgres. But, realistically, the primary motivation behind that decision would be because Postgres is available on AWS, and that would centralize more of our operations. (DocumentDB is, of course available. Its not Mongo. I'd be curious to hear from people who actually had Mongo deployments and were able to move to DocumentDB; its missing so many o…

> We're not going to be migrating terabytes of data You may have dramatically less 'real data' than mongo makes you think you do. I migrated one of our mid sized database out of mongo and into PG a couple years ago. The reduction in size was massive. One table in particular that was storing a small number of numeric fields per doc went from ~10GB to ~50MB. I wouldn't expect this with all datasets of course, but mongo…

Not OP but I think it's more about the importance of the said data, number of collections to think about and so on. Regarding your point, I would guess some index changes might have had a significant impact here.

Re: Ask HN: Do you still use MongoDB?

#93
Yes

Our use case is dynamic dashboards generation where a document contains multiple components for our frontend to render. Having a simple unstructured database really helps us build the dashboard efficiently. Using a relational database would increase the development time of each dashboard tremendously and having relational integrity would make it even worse.

Having a simple document with everything needed is a much nicer experience. Granted, our use case is very limited and it is read only.

Re: Ask HN: Do you still use MongoDB?

#94

Anyone has thoughts about cassandra and how it compares to mongodb? There seems to be a big enterprise push with azure's cosmosdb, but I've not heard much about it from people who have actually used it.

Unless you can hire Cassandra engineers who have enough experience maintaining clusters, or you can afford to pay DSE to do that for you, working with Cassandra will be quite the burden.

The advancement of PostgrSQL has been amazing, and much credit is due indeed to the NoSQL community’s innovations. I cannot comment of MongoDB except to say that it is quite different than Cassandra.

To summarize, be sure you really need Cassandra and are able to dedicate the appropriate resources to it before taking the plunge.

Re: Ask HN: Do you still use MongoDB?

#95
post #82
post #27

No. Every time I've used mongodb we've ended up regretting it for one reason or another. And migrating to a different database after launch is a huge hassle. I've done a couple projects where we kicked off with postgres using JSONB columns for early iteration. Then we gradually migrated to normal SQL columns as the product matured and our design decisions crystallized. That gave us basically all the benefits of mongo…

I never understood the appeal of the JSON to SQL columns workflow. At least with the ORM(-ish) tools I worked with, it always felt much more straightforward to just change classes within the application code and automatically generate the respective migrations files to be run on the relational database, than having to interact as a human with json (for the app as well as for business intelligence and reporting/monito…

> I never understood the appeal of the JSON to SQL columns workflow.

The appeal is non-technical.

Writing good migrations, having tests around them to ensure they didn't leave the DB in an inconsistent state if a subset of them failed requires good understanding of a RDBMS and the specific product.

You'll be surprised how many engineers don't meet that criteria.

The JSON to SQL columns workflow allows any developer to offload what a RDBMS does into the client/server/bootstrap code.

At that point the DB is like a key-value store and you get to claim you are using Postgresql.

Is that what I would use if I had reliability and performance in mind?

No... but it's way cheaper (and quicker) to find devs who can do this (JSON to SQL columns workflow) than devs who can write well tested, reliable and non hacky migrations.

Often at a startup, reliability and performance have lower priority than getting some features out the door in a day.

Re: Ask HN: Do you still use MongoDB?

#96
post #79

Someone needs to explain to me what the benefits of NoSQL with MongoDB are when you have the JSONB column type and the ability to query and insert at the field level with JSON in PostgreSQL? Maybe there's some benefit, but I'm not seeing that major "gotta have it" feature or performance gains. And I ask this question seriously, because I just don't know the answer.

Having to work with MongoDB, I say only benefit is you don't need to plan or think through your design. Which in my view is not really a benefit. You end up checking for null properties everywhere.

Re: Ask HN: Do you still use MongoDB?

#97
post #69

Earlier quoted context omitted.

That's my attitude as well. RethinkDB, in comparison, had a much better attitude of "reliable first, fast later". Unfortunately, it turned out that when you're a database, it doesn't matter how much data you lose, only how fast you are while losing it.

The PostgreSQL community is a nice counterexample - perfectly gigantic and growing marketshare, and very very reliable.

Listening to the community and using Postgres is my biggest regret. In hindight, given our scale, any database would have worked. There is no built in solution for high availability with multiple VPS, and having one server alone isn't enough availability for me.

Re: Ask HN: Do you still use MongoDB?

#99
post #88
post #74

Yes. If we were going to start from scratch today, we'd probably use Postgres. But, realistically, the primary motivation behind that decision would be because Postgres is available on AWS, and that would centralize more of our operations. (DocumentDB is, of course available. Its not Mongo. I'd be curious to hear from people who actually had Mongo deployments and were able to move to DocumentDB; its missing so many o…

> We're not going to be migrating terabytes of data You may have dramatically less 'real data' than mongo makes you think you do. I migrated one of our mid sized database out of mongo and into PG a couple years ago. The reduction in size was massive. One table in particular that was storing a small number of numeric fields per doc went from ~10GB to ~50MB. I wouldn't expect this with all datasets of course, but mongo…

Unless this has changed in recent years, the BSON format that Mongo uses is more or less JSON optimized for parsing speed and takes more or less as much space as storing your entire database in JSON.

JSON is a great format for simplicity and readability but as a storage format it's hard to come up with one that's more bloated.

Re: Ask HN: Do you still use MongoDB?

#100
post #62

There is a very recent Jepsen report on MongoDB. http://jepsen.io/analyses/mongodb-4.2.6 > Jepsen evaluated MongoDB version 4.2.6, and found that even at the strongest levels of read and write concern, it failed to preserve snapshot isolation. Instead, Jepsen observed read skew, cyclic information flow, duplicate writes, and internal consistency violations. Weak defaults meant that transactions could lose writes and…

I don't understand half of what this means. Does it rule out MongoDB if you care about your data?
Post reply on HN