A tool for when the only environment is production

Here's a thing they don't tell you in the certification track: a huge amount of real database work happens on live production systems, with no test bed that actually resembles them.

You can have the tidiest lab in the world and it still won't have your prod's data volume, your prod's weird legacy login, the linked server someone set up in 2018, or the exact failover topology you're staring at during an incident. So when something breaks at scale, you're often diagnosing it on the live system — because that's the only place the problem exists.

That's a nerve-wracking place to work. One wrong keystroke on a busy production box has consequences a lab never will. And the tooling most of us reach for makes it worse: it wants to connect, to run, to change things, to "just fix it for you." On prod, "just fix it for you" is exactly the sentence that ends careers.

So I built the opposite kind of tool.

The idea: reason about the system without touching it

The core move is a hard separation between collecting and thinking. Collecting is where the danger lives — that's the part that runs against the live system. So collection stays in your hands, as read-only queries you run in the tools you already trust, and it never does anything but SELECT.

The thinking — the triage logic, the "here's what this means, here's what to check next, here's the fix and how risky it is" — moves entirely into a page that runs in your browser. You paste the output in. It parses, classifies, and lays out the next step. It never opens a connection to anything.

That constraint sounds limiting until you're the one holding the keyboard at 2am on a system you cannot afford to break. Then it's the most reassuring property a tool can have. It cannot fat-finger a change. It cannot lock a table. It cannot connect to the wrong instance. It has no hands.

Why "no test bed" is the normal case, not the exception

The industry likes to pretend prod-only work is a failure of process. Sometimes it is. But often it's just reality: some problems only reproduce at production scale, under production load, against production data quirks. A replication lag that appears at 40 million rows. A plan that goes bad only when the stats look like Tuesday afternoon. A failover artifact that exists precisely because it's your failover.

You can't lab those. You can only work them where they live — carefully. And "carefully" has a concrete meaning: read before you write, understand before you act, and use tools that can't act for you.

So the whole kit is built to make careful the path of least resistance. Read-only collection. Paste-based analysis. Nothing that connects, nothing that changes state, nothing that phones home. A companion script for auditing a fleet that only ever runs SELECT. A training simulator that runs entirely in the browser so people can practice the scary procedures on a fake system before they ever do it on a real one.

The unexpected payoff

I built this to keep myself safe on live systems. What I didn't expect: a tool that reaches for nothing is also a tool that goes anywhere. It doesn't care what version you're on, whether you're connected through six jump boxes, or whether the box you're on can even see the internet. Text in, triage out. No install, no account, no connection to review.

Which means the same properties that make it safe to run on production also make it easy to hand to the next person. The safest tool and the most shareable tool turned out to be the same tool. That's not a coincidence — it's what happens when you design around doing no harm instead of around doing everything.