Viewing profile — computerfan494

By "patch" I am talking about the public commit. Updated binaries were made available when the CVE was published.

That's a good question. I suppose that posting the commit makes it incredibly obvious how to exploit the issue, so maybe they wanted to wait a little bit longer for their on-prem u…

The author of this post is incorrect about the timeline. Our Atlas clusters were upgraded days before the CVE was announced.

If this is a result of that vulnerability, Ubisoft only have themselves to blame. Our support contacts ensured that we knew about the vulnerability as early as possible and gave us…

We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.

Postgres violated serializability on a single node for a considerable amount of time [1] and used fsync incorrectly for 20 years [2]. I personally witnessed lost data on Postgres b…

Yes, and my point is that this customer switching to running their own MongoDB instances on EC2 like Atlas does would reduce the bill by less than 50% because the rates that they a…

You can look at this particular bill and observe that more than 50% of the cost was going to AWS.

There's definitely MongoDB markup, but a full 33% of their bill was AWS networking costs that have nothing to do with Atlas.

Most of the cost in their bill wasn't from MongoDB, it was cost passed on from AWS

I can assure you that Stripe does not regret the decision.

Maybe it's only me, but I just don't write that much code. I try to change less than 100ish lines per day. I try to keep codebases small. I don't want to run a codebase with hundre…

I'm not planning to because there is no documented protocol. If there were, I might! As a result, I can't use FoundationDB.

The hard part is that there is no client spec you can follow as a third-party. Everything is implementation-defined. If you're out-of-tree, your code can break at any time. If the …

FoundationDB is very cool, but I wish it didn't require linking in their C library to talk to it. The client story is not good.

MongoDB is a very good database, and these days at scale I am significantly more confident in its correctness guarantees than any of the half-baked Postgres horizontal scaling solu…

The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you'v…

I will copy and paste a comment I wrote here previously: "MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every lan…

I have been using it in production for more than a year. There were some early hiccups associated with my use-case that were resolved on upgrade and with a bit of tuning. Otherwise…

MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every language you could want (no C library re-use), is reasonably …

My understanding of what the OP was discussing is an optimistic locking system where the nodes only accept commits if the last issued token matches the token included in the commit…

I feel like you're dancing around admitting the core issue that Martin points out - RedLock is not suitable for systems where correctness is paramount. It can get close, but it is …

Locking without a timeout is indeed in the majority of use-cases a non-starter, we are agreed there. The critical point that users must understand is that it is impossible to guara…

In the above description of optimistic locking, it is assumed that it is impossible to issue the same token to multiple clients. Nodes can agree that a given token has also never b…

To be honest I've long been puzzled by your response blog post. Maybe the following question can help achieve common ground: Would you use RedLock in a situation where the timeout …