:cough: So it's been 10 years.
This is a horrendous design flaw for a piece of software that calls itself a database.
Ignoring that 64-bit is hardly new or controversial, even at that time, or that it even represents any form of onus on IT…
In relation to errors passing silently, there's a giant warning displayed if you attempt to utilize the 32-bit version, and it's been there for a very long time, plus red flags of warning on the download page and documentation relating to it. Similar to the warning emitted if it detects you have THP (Transparent Huge Pages) enabled in your kernel, which violates assumptions over memory pages being 4KiB and the performance guarantees of allocation operations.
If you tell a database to store something, and it doesn’t complain, you should safely assume that it was stored.
Or you should check your assumptions before relying on them! By default, writes only confirm the primary heard your request, not that the request was completed or even written to disk-backed journal. If you want to use things safely, invest in learning the properties of their operation!
I'm very sorry but developers can't abandon all responsibility for their technical choices. You make your bed, you have to lie in it. Or get fired for failing to RTFM and leaking your company's data (failing to secure) or encouraging data loss (failing to set a write concern).
From the comments…
Many tools have gotchas… [calls out specific tools]… but there are alternatives which are easy to use… [refuses to name them]
Thanks for coming out. Back when this article was originally published, I was pushing 3.8 million inserts/second on one RPC collection, and storing hundreds of millions of records totalling ~30TB of personal data in a tag-based non–hierarchical GridFS collection. Today that dataset is up to 56TB. On the professional front, my production platform applications are processing 15K requests per day or so, storing a hair shy of 15M records.
Sure can use alternatives that are easier to use… I guess?
Dang, "revelation on the stair", but I should have asked if he preferred the "guarantees" of SQLite. (Which is a trap, as the DDL statements in SQLite essentially have no effect. Declare a field an integer, slap some string or binary data in there. SQLite's a honeybadger which don't care, taking a CSV and pretending it's SQL.)
Also that the 2GB limit is due to the 2/2 limit/split of the kernel operating in 32-bit mode. Not MongoDB.