Of course, the support portal requires you to auth to use it...to get help with auth failing.

Anyone else seeing issues getting in to their dashboard?

Edit: Auth started working for us and dashboard access became available for us around 5:15 pm ET.

The login issues are unrelated to the security incident. We notified all of our customers and users concurrently resulting in a spike in login attempts. Please try again in a few minutes if you are still having trouble logging in.

Please continue to monitor our alerts page: https://www.mongodb.com/alerts

I'm trying my personal account as well and it's telling me MFA isn't set up (it is) and it's making me go through the MFA setup flow again. All attempts to setup another 2FA code in 1Password or to get even an SMS code sent to my phone are failing.

Edit: Personal account with a TOTP 2FA is working again now as well.

This is feeling worse than they're letting on to.

But without two factor, only your account credentials are needed.

So yeah, it's definitely better than nothing, you are effectively forcing your opponent to social engineer your carrier, and doing that generally requires knowing the full number and usually at least your name, if not more identifying information that's harder to get, like social security number or equivalent.

Sure, TOTP or other two factor mechanisms are better because they require access to one of your authenticated devices (assuming the TOTP isn't done by a secure enclave), but SMS two factor is definitely better than disabling two factor.

No. I did not. Nor do I now.

I had a TOTP setup in 1Password and Mongo was telling me MFA _wasn't_ set up and sending me through the MFA setup flow again.

All options, SMS included, were failing in that MFA setup flow they pushed me in to.

They're back now and my existing TOTP token is generating one time use passwords that work now.

I like this tbh and I hope people won't punish them for not including more info when this is clearly in the early days of investigation.

I want answers.

I'm sure they want answers too, but they're working on it, and this is what they have right now.

You do not have the option of (C) Vendor should tell me about a breach they don't yet know about.

For all the shit MongoDB gets, this is something that people should take a step back and recognize as very high in integrity, transparency, and trust.

Other businesses should follow their lead here.

I'm more inclined to do business with MongoDB because they've demonstrated these principles first-hand.

Is there some context I’m missing, or is this a modern security team recommending password rotation?

https://pages.nist.gov/800-63-FAQ/#q-b05

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.

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

What did not happen (yet) is complete AWS meltdown

Hi Redacted,

MongoDB is investigating a security incident involving unauthorized access to certain MongoDB corporate systems. This includes exposure of customer account metadata and contact information. At this time, we are NOT aware of any exposure to the data that customers store in MongoDB Atlas.

We detected suspicious activity on Wednesday (Dec. 13th, 2023) evening US Eastern Standard Time and immediately activated our incident response process. We are still conducting an active investigation and believe that this unauthorized access has been going on for some period of time before discovery. We have also started notifying relevant authorities.

What should you do next? Since we are aware that some customer account metadata and contact information was accessed, please be vigilant for social engineering and phishing attacks. If not already implemented, we encourage all customers to activate phishing-resistant multi-factor authentication (MFA) and regularly rotate passwords. MongoDB will continue to update mongodb.com/alerts with additional information as we continue to investigate the matter.

Sincerely, Lena Smart MongoDB CISO

https://youtube.com/watch?v=b2F-DItXtZs

So fsync is called on every write.

Even so, not flushing each write is not as bad as it sounds, if you have a 3-node replicaset and your w-parameter is set to majority (default), it means at least 2 servers have the write in memory. It would take both of them crashing at the same time for the unflushed write to be lost.

The idea is that MongoDB allows you to choose which corner of the CAP triangle you want, if you chose AP, that’s your decision. The defaults can of course be argued and I believe it’s been gradually moving over to more and more C for each version. Nowadays the journal does get flushed as next comment described.

"Jepsen Disputes MongoDB’s Data Consistency Claims" - https://www.infoq.com/news/2020/05/Jepsen-MongoDB-4-2-6/

[1] https://jepsen.io/analyses/mongodb-4.2.6

[2] https://jira.mongodb.org/browse/SERVER-48307

- Queries look more like application code so you're not wasting mental cycles and time trying to translate an idea into a SQL query. From experience, this leads to less-fragile queries.

- Little to no concern over injection attacks (you have to go out of your way to create potential for them).

- Easier to write non-trivial queries than with SQL (IMO).

- Type-casting data can be done in code as opposed to with SQL you have to use inline, platform-specific functions like field_name::timestamp.

- A single source of truth for how to query and develop with it (with SQL, you're almost always developing against a flavor of it).

- Scales reasonably well (and easily) for a majority of use cases.

- No room for dogmatic fervor/confusion around a specific variety of MongoDB as there's only one variety.

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."

At first at least, haven't checked in on that in awhile

In 99% of the cases, even if you need a flexible schema, PostgreSQL will remain the best choice.

But what's the advantage of Postgresql in this case?

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

Note: I work at MongoDB

Isn't firebase built on top of mongoDb?

This is not easy to do with PostgreSQL, which we use for all other scenarios requiring a DB.

[0] https://pastebin.com/v2MiV8PE

[1] https://pastebin.com/RmLuGzAY

For now, there are way too many critical issues found late in the release cycle.

I think it only hurts people who want to freeride the project and extend it for selfish personal gains. That's OK by me.

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.

Note AWS significantly contributes to PostgreSQL and MySQL communities (though you could always want even more) but of course does not to MongoDB. While this is fine for MongoDB Inc I think it is not great for MongoDB community at large

Nosql is a fun target to beat up on of late. But there are good, even infamous, reasons to avoid SQL. Particular if you want to accomplish flexible record queries from untrusted clients.

Your response seems to betray a certain ignorance of mongo. Don't you realize that mongo has indexes?

For handling documents, this blog post covers the topic in some depth.

https://jimb-cc.medium.com/postgres-jsonb-meets-mongodb-part...

Might I suggest you actually use mongo on a project before engaging further on the topic. It clearly has had a lot more thought put into it in the context of json documents.

If postgres works great for your use cases, great, go be happy with the tool.

https://github.com/obartunov/sqljsondoc/blob/master/jsonpath...

But a query language within a query language feels bolted onto something alien to do something pretty basic. Pass. If I'm teaching this to new engineers, pass also.

[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

[2] https://opensource.stackexchange.com/q/13888

[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915537

[4] https://fedoraproject.org/wiki/Changes/MongoDB_Removal

[5] https://bugzilla.opensuse.org/show_bug.cgi?id=1122267

[6] https://lists.archlinux.org/archives/list/arch-dev-public@li...

I am not sure really.

"It should be noted that the new license maintains all of the same freedoms the community has always had with MongoDB under AGPL - they are free to use, review, modify, and redistribute the source code. The only changes are additional terms that make explicit the conditions for offering a publicly available MongoDB as a service.

Obviously, this new license helps our business, but it is also important for the MongoDB community. MongoDB has invested over $300M in R&D over the past decade to offer an open database for everyone, and with this change, MongoDB will continue to be able to aggressively invest in R&D to drive further innovation and value for the community."

We built an email service (IMAP support added a month ago) and wrote a WebSocket to SQLite layer to solve our encryption at rest needs for storage.

See our deep dive at https://forwardemail.net/blog/docs/best-quantum-safe-encrypt... for insight.

Another requirement was full text search on the mailboxes with the data itself being encrypted at rest (SQLite fit our needs for that too; not many others provide this). We have a comparison chart at https://forwardemail.net/blog/docs/best-quantum-safe-encrypt....

https://docs.percona.com/percona-server-for-mongodb/5.0/data...

Kind of makes me unsure if it’s going to be the right choice.

Just pick postgres. If you have unstructured data as input, either put in the effort to create some kind of schema for it if you can or just use jsonb if you can’t.

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?

Nowadays, PostgreSQL has JSON/JSONB types, a full suite of extensions like pgvector and PostGIS, and I can scale with Citus or use it in any of the big managed clouds.

From a functionality perspective, MS SQL Server makes a more compelling alternative to me simply by way of its native graph database support.

Only on hacker news do I get downvoted by autistic people who refuse to accept any dissidents from the hive mind.

Plus all the Mongo horror stories from people who I know and hold in high esteem. And recently talking to a data person explaining what a pita getting data out of their Mongo monstrosity into a format adequate for analysis.

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