There is a particular half second I want to talk about.
You have four connections open. Two of them are named something like shop-prod and shop-prod-eu, because whoever set up the cluster was in a hurry and now it is three years later and nobody is renaming anything. You have been working in staging all morning. You paste a query, hit run, and somewhere between the keystroke and the result you look at the sidebar and your stomach drops.
Nine times out of ten it is fine. It was a find. Nothing happened. You sit there for a moment feeling the adrenaline drain out of your hands and then you go back to work.
The tenth time is why I am writing this.
The industry’s answer is “be careful”
Open any MongoDB client and look for the thing that stops you from writing to production. Compass has no such thing. Studio 3T has a read-only mode that is a preference you set and then forget you set. Most of the rest treat it the same way: an option, buried somewhere, off by default, and entirely your responsibility to remember.
The unstated position is that this is a discipline problem. Careful engineers check the connection name. Careful engineers do not run updates at 11pm. Careful engineers do not have four clusters open at once.
I have been that engineer, and I have also been the version of that engineer who has not eaten since lunch and is trying to ship something before a call. They are the same person. Discipline is a state, not a property, and building safety on top of a state means the safety disappears at exactly the moment you need it most.
A guard that depends on you remembering is not a guard. It is a note to self.
Where the guard has to live
So we started from a different question when building Ognom. Not “how do we let people turn on read-only” but “if a connection is marked production, how many paths exist through this application that can still write to it?”
Count them honestly for any database client and the number is uncomfortable.
There is the obvious one, the update button in the document view. There is the delete on a row. There is the keyboard shortcut you hit by muscle memory. There is the shell, where db.orders.updateMany() is just text and nobody is parsing your intent. There is the aggregation pipeline, where a $out or $merge stage at the end quietly writes an entire collection and looks, right up until it runs, exactly like a read. There is the index editor. There is the import dialog.
If the read-only check lives in the UI, you have to remember all seven of those places, and then you have to remember them again next quarter when somebody adds an eighth. Somebody will forget. That is not a criticism of anyone, it is just what happens to checklists over time.
The only version of this that holds is one where every write, without exception, goes through a single door, and the check sits at that door.
In Ognom, that door is the API layer. Every operation that mutates anything, whether it originated from a button, a shortcut, a shell statement or a pipeline stage, passes through the same place, and that place asks one question before it does anything else: is this connection marked production, and is edit mode on?
The UI has no say in it. The shell has no say in it. There is no code path that reaches the driver without going past the check, which means there is nothing to remember and nothing to keep in sync. A new feature added next year inherits the guard for free, because there is nowhere else for it to send a write.
This is the whole point of the title. If read-only is a setting, it protects the cases somebody thought of. If it is architecture, it protects the cases nobody thought of yet.
What it looks like when you use it
Mark a connection as production and it opens read-only. Every time. Not the first time, not until you change it, every single time you open it.
The connection carries a red tag on the rail, so the blast radius is visible without you going looking for it. This matters more than it sounds. Most database accidents are not failures of knowledge, they are failures of attention, and the fix for a failure of attention is to put the information where the eye already is.
When you do need to write, you turn on edit mode from the status bar. Ognom asks first, and the dialog is deliberately plain about it: this connection is marked production, in edit mode every write goes straight to the live server. You confirm. You get edit mode for that session only. Close the app, come back tomorrow, and you are read-only again, because a permission you granted yesterday for one task should not still be sitting there today.
There is also a plain read-only mode for any connection you have not marked, for when you want to browse a server you do not know well without thinking about it.
The same reasoning, applied everywhere else
Once you accept that attention is the scarce resource, a lot of other decisions follow from it.
Dropping a collection in Ognom tells you exactly what it removes, in documents and indexes, and then makes you type the collection’s name. Typing the name is not security. It is a speed bump. It takes the action out of muscle memory and puts it back into conscious thought, which is the only thing that actually helps.
It also offers a BSON dump before it drops, and if you cancel the backup, the drop cancels too. That last part was a small decision that turned out to matter. The alternative, where cancelling the backup silently proceeds with the drop, is technically defensible and completely wrong.
Bulk delete refuses an empty filter outright. Not a warning, a refusal. An empty filter on a delete is never what anybody meant.
And every bulk write shows you the affected count with sample _ids before it runs, because “this will modify 4 documents” and “this will modify 40,000 documents” should not look identical until after you press the button.
What this costs
It would be dishonest to write all this and not mention the tradeoff.
Ognom is slower to do dangerous things with. If you are the sort of person who genuinely does want to run a quick update against production twenty times a day, you will find the edit mode toggle mildly annoying by the fourth time. That is a real cost and I am not going to pretend it is a feature.
We took it deliberately. The friction is proportional to the damage, and it is front-loaded onto the actions that are hard to undo. Reads are instant. Writes to a normal connection are instant. Only the specific combination of production and destructive is slow, and it is slow on purpose.
Why we built it this way
Ognom is free, MIT licensed, and has no telemetry, no account and no sign-in. It is one of three open source tools our team at Broadifi maintains, alongside CalmAPI and TerCTL, and the three of them share a fairly simple idea: a tool should protect you from your worst moment, not just serve you well in your best one.
You can download it for macOS, Windows or Linux from ognom.dev, and the source is on GitHub.
If you have your own version of that half second story, I would like to hear it. Most of what is in Ognom is there because somebody on the team lived through something once and did not want to again.
2 comments