Hacker News: computerfan494

New comment by computerfan494 in "MongoDB Server Security Update, December 2025"

computerfan494 — Tue, 30 Dec 2025 02:13:17 +0000

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

New comment by computerfan494 in "MongoDB Server Security Update, December 2025"

computerfan494 — Tue, 30 Dec 2025 01:02:58 +0000

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 users who were slow to patch?

New comment by computerfan494 in "MongoBleed Explained Simply"

computerfan494 — Sun, 28 Dec 2025 23:28:06 +0000

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

New comment by computerfan494 in "Rainbow Six Siege hacked as players get billions of credits and random bans"

computerfan494 — Sun, 28 Dec 2025 23:02:58 +0000

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 a clear guide to remediation for our self-hosted clusters. Our Atlas clusters were automatically patched before this was announced publicly. You'd have to be running your database open to the internet (already a mistake), ignore the advice to simply turn off zlib, and ignore the fixed versions that have been available for over a week.

If you're going to be in the business of running your own critical infrastructure, you better have spent a lot of effort planning for these situations, because they are inevitable. Otherwise, it's easier to just pay a vendor to do it for you.

New comment by computerfan494 in "MongoBleed"

computerfan494 — Fri, 26 Dec 2025 22:06:11 +0000

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

New comment by computerfan494 in "Go ahead, self-host Postgres"

computerfan494 — Sat, 20 Dec 2025 21:45:58 +0000

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 because of the fsync issue.

Database engineering is very hard. MongoDB has had both poor defaults as well as bugs in the past. It will certainly have durability bugs in the future, just like Postgres and all other serious databases. I'm not sure that Postgres' durability stacks up especially well with modern MongoDB.

[1] https://jepsen.io/analyses/postgresql-12.3

[2] https://archive.fosdem.org/2019/schedule/event/postgresql_fs...

New comment by computerfan494 in "We cut our Mongo DB costs by 90% by moving to Hetzner"

computerfan494 — Fri, 14 Nov 2025 06:41:28 +0000

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 are charging mean that their cut is less than what AWS is getting from this customer.

New comment by computerfan494 in "We cut our Mongo DB costs by 90% by moving to Hetzner"

computerfan494 — Thu, 13 Nov 2025 21:22:44 +0000

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

New comment by computerfan494 in "We cut our Mongo DB costs by 90% by moving to Hetzner"

computerfan494 — Thu, 13 Nov 2025 21:21:33 +0000

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

New comment by computerfan494 in "We cut our Mongo DB costs by 90% by moving to Hetzner"

computerfan494 — Thu, 13 Nov 2025 15:54:38 +0000

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

New comment by computerfan494 in "Conformance checking at MongoDB: Testing that our code matches our TLA+ specs"

computerfan494 — Tue, 03 Jun 2025 00:55:39 +0000

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

New comment by computerfan494 in "My AI skeptic friends are all nuts"

computerfan494 — Mon, 02 Jun 2025 21:31:44 +0000

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 hundreds of thousands of lines of code in a production environment.

New comment by computerfan494 in "Foundation DB Record Layer SQL API"

computerfan494 — Wed, 14 May 2025 00:40:03 +0000

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

New comment by computerfan494 in "Foundation DB Record Layer SQL API"

computerfan494 — Thu, 08 May 2025 14:12:01 +0000

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 project committed to a protocol, client authors could write libraries outside of the main project.

New comment by computerfan494 in "Foundation DB Record Layer SQL API"

computerfan494 — Thu, 08 May 2025 02:08:20 +0000

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.

New comment by computerfan494 in "Jepsen: Amazon RDS for PostgreSQL 17.4"

computerfan494 — Tue, 29 Apr 2025 21:41:51 +0000

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 solutions. I have run both databases at seven figure a month spend scale, and I would not choose off-the-shelf Postgres for this task again.

New comment by computerfan494 in "Fauna Service Winding Down"

computerfan494 — Wed, 19 Mar 2025 21:25:31 +0000

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've probably spent a good amount of engineering time painstakingly sharding your database at the application level and hoping you've done it correctly. MongoDB solves these problems out of the box, among others. I have run both of these above 1M a month in spend and I would certainly choose MongoDB for this over Postgres. If you plan on never spending a lot on your database, I do like Postgres a lot, still.

New comment by computerfan494 in "MongoDB acquires Voyage AI"

computerfan494 — Mon, 24 Feb 2025 17:27:27 +0000

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 language you could want (no C library re-use), is reasonably vendor-neutral and can be run locally, and the data modeling it encourages is both preferential for some people as well as pushes users to avoid patterns that don't scale very well with other models. Whether these things are important to you is a different question, but there is a lot to like that alternatives may not have answers for. If you currently or plan on spending > 10K per month on your database, I think MongoDB is one of the strongest choices out there."

I have also run Postgres at very large scale. Postgres' JSONB has some serious performance drawbacks that don't matter if you don't plan on spending a lot of money to run your database, but MongoDB does solve those problems. This new documentdb extension from Microsoft may solve some of the pain, but this is some very rough code if you browse around, and Postgres extensions are quite painful to use over the long term.

The reality is that it is not possible to run vanilla Postgres at scale. It's possible to fix its issues with third party solutions or cobbling together your own setup, but it takes a lot of effort and knowledge to ensure you've done things correctly. It's true that many people never reach that scale, but if you do, you're willing to spend a lot of money on something that works well.

New comment by computerfan494 in "How rqlite is tested"

computerfan494 — Wed, 15 Jan 2025 15:51:00 +0000

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 it has been very stable. I'll say that I wish the official language bindings were tested more like rqlited itself. They've been more problematic than the database.

New comment by computerfan494 in "Database mocks are not worth it"

computerfan494 — Mon, 30 Dec 2024 21:10:22 +0000

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 vendor-neutral and can be run locally, and the data modeling it encourages is both preferential for some people as well as pushes users to avoid patterns that don't scale very well with other models. Whether these things are important to you is a different question, but there is a lot to like that alternatives may not have answers for. If you currently or plan on spending > 10K per month on your database, I think MongoDB is one of the strongest choices out there.

Also want to add that you can definitely use MongoDB (or any other database) in a way that doesn't scale well. I have personally run MongoDB at petabyte scale and had a relatively great experience.