Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB security notice

mongodb.com

Post reply on HN
Print view View original

161–170 of 198 posts

Re: MongoDB security notice

#161

Post by c0pium »

merek wrote: post #138
cpursley wrote: post #122

Earlier quoted context omitted.

Mongo is never the right choice. Postgres is nearly always the right choice, however.

Legitimate question, please don't downvote. Are you basing this opinion on: - popular HN opinion - issues that Mongo experienced in its infancy - mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems Or are you basing it on extensive experience with wide range of use cases?

Much like saying “no offense” doesn’t make something not offensive, saying “honest question” doesn’t make a question not disingenuous. If you find yourself typing “don’t downvote” you should consider rephrasing your question to not be worthy of downvotes.

This post could just be “can you explain your experiences that have lead you to this conclusion” and we’d all be better off.

Re: MongoDB security notice

#162

Post by ronabop »

twisteriffic wrote: post #144
richbell wrote: post #140

Earlier quoted context omitted.

Regularly rotating secrets for applications is good. Forcing users to regularly rotate their passwords is not so good.

Correct! NIST recommends against forcing password expiry unless the password is known to be compromised. https://pages.nist.gov/800-63-FAQ/#q-b05

Thankfully all of my users are extreme statistical aberrations who do not re-use the same memorized password (or a variation on it) for more than one thing, ever, at all OR they diligently watch every single possible place they have ever re-used any of their memorized passwords, with the globally mandated and complied with reporting, so they can know if a password they once re-used at grandmas-cookies.blog.example.com has been compromised.

The fact that all websites, servers, systems (etc.) check to see if passwords are known to be compromised (since NIST says verifiers will do that) makes things a lot easier, too.

Re: MongoDB security notice

#163

Post by didip »

nextworddev wrote: post #126
PeterZaitsev wrote: post #101

This highlights risks of extreme consolidation - even if Atlas customers were not affected it is natural for them to be concerned after announcement overwhelming web site or support channels. More independent MongoDB DBaaS providers is what would offer true redundancy in this case, though it is highly restricted due to SSPL license change. Hopefully FerretDB will be successful building feasible alternative

“Extreme consolidation” - wait till us-East-1 goes down

Friends don’t let friends run on us-east-1. Consolidate on us-west-1 or us-west-2 instead.

Re: MongoDB security notice

#164

Post by [deleted] »

c0pium wrote: post #161
merek wrote: post #138

Earlier quoted context omitted.

Legitimate question, please don't downvote. Are you basing this opinion on: - popular HN opinion - issues that Mongo experienced in its infancy - mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems Or are you basing it on extensive experience with wide range of use cases?

Much like saying “no offense” doesn’t make something not offensive, saying “honest question” doesn’t make a question not disingenuous. If you find yourself typing “don’t downvote” you should consider rephrasing your question to not be worthy of downvotes. This post could just be “can you explain your experiences that have lead you to this conclusion” and we’d all be better off.

[deleted]

Re: MongoDB security notice

#165

Post by yawaramin »

rglover wrote: post #146
djrobstep wrote: post #134

Earlier quoted context omitted.

> Because you're not developing against a schema, you can, for example, retool a feature and its data quickly without having to stress about migrations. A big advantage for a startup looking to move fast. Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy.

> Why wouldn’t you need to worry about migrations without developing against a schema? You’ll need to worry more about migrations because your data will be more messy. If you're careless with your data, yes. "With great power comes great responsibility."

Being careful with my data is exactly why I use a strongly typed RDBMS in the first place.

Re: MongoDB security notice

#166

Post by yawaramin »

winrid wrote: post #143
cpursley wrote: post #124

Earlier quoted context omitted.

Postgres does all that plus 100x.

But the horizontal scaling is easier with Mongo than Citus.

But you don't need to horizontally scale if you use a beefy Postgres instance. Horizontal scaling is a problem created by using an inefficient DB in the first place.

Re: MongoDB security notice

#167

Post by winrid »

yawaramin wrote: post #166
winrid wrote: post #143

Earlier quoted context omitted.

But the horizontal scaling is easier with Mongo than Citus.

But you don't need to horizontally scale if you use a beefy Postgres instance. Horizontal scaling is a problem created by using an inefficient DB in the first place.

I have DB clusters with masters with a terrabyte of ram. Going beyond that is a PITA with warming up cache, backups, and so on. There is a reason there's a huge industry for shared databases.

Also, query for query, Mongo isn't going to be that much slower than PG, and faster for some usage patterns...

Re: MongoDB security notice

#168

Post by winrid »

rglover wrote: post #147
winrid wrote: post #141

Earlier quoted context omitted.

It could be rephrased as "worry about them later" :P gotta get those returns on the VC money and pawn those issues onto the next team in 7yrs :)

Not necessarily. If you're utterly careless, sure. A MongoDB migration is far less of a headache than a SQL one (you're just writing code to map/replace values). With SQL, you have to be frustratingly surgical about everything which can slow momentum to a crawl (read: punishment for mistakes in the migration is far worse than with MongoDB in my experience).

I completely agree! Kind of preaching to the choir :)

Re: MongoDB security notice

#169

Post by peterfarkas »

ranting-moth wrote: post #15
wg0 wrote: post #4

Irrelevant but curious if MongoDB is still being picked up for Greenfield projects given it's licensing.

Their license "is to require that enhancements to MongoDB be released to the community." I think it only hurts people who want to freeride the project and extend it for selfish personal gains. That's OK by me.

Anyone can provide Postgres, MySQL or other open source databases as a service.

For this reason, there are many providers to choose from, and there is a healthy amount of innovation and competition in the space. Prices are set by market and demand, as it should be.

And then there is MongoDB where only a handful of providers could negotiate a license, and the price is set by MongoDB Inc.

In my opinion this is by no means "fine" from a user perspective as we are talking about database software.

If anyone did freeriding, it is MongoDB Inc. who chose to freeride on the open source community for marketing purposes, before switching to SSPL.

Re: MongoDB security notice

#170

Post by nojvek »

merek wrote: post #138
cpursley wrote: post #122

Earlier quoted context omitted.

Mongo is never the right choice. Postgres is nearly always the right choice, however.

Legitimate question, please don't downvote. Are you basing this opinion on: - popular HN opinion - issues that Mongo experienced in its infancy - mis-modelling highly relational data on a non-relational DB, and blaming the DB for ensuing problems Or are you basing it on extensive experience with wide range of use cases?

We started our startup on Mongo. Hit some pretty hard performance problems and eventually did a multi month long migration to Postgres (Aurora on AWS).

MongoDB is only a valid choice if all you're doing is story key document pairs. The moment you need joins or any sort of aggregations like count/sum e.t.c - Mongo perf is horrendous. Postgres runs circles around Mongo in every way.

With jsonb columns, not much is lost. SQL is a huuuuge bonus. Mongo query language is a giant pain for everyone on team to learn and manage.

Post reply on HN