Diagnosis before prescription.
I'm Michael Paycer — a Senior SQL Server DBA and Developer in St. Cloud, Minnesota. For about twenty years I've done one thing well: find the real cause before I touch the fix. It's also why I read the Stoics, study the Ruy Lopez, and keep an eye on which star in Orion is dying. This page is the argument that those aren't three different people.
What I actually do all day
My job starts with three things, in this order: security, high availability, and reliability. Everything else a business wants from its data — speed, reporting, clean migrations — depends on getting those right first. I've worked across every version of SQL Server from 2000 through 2025, on-premises and in the cloud, on Azure SQL and AWS RDS, behind IIS and .NET applications that can't afford to be down.
The problems that land on my desk sound familiar after twenty years. A query that used to return in 200 milliseconds now takes forty seconds and nobody changed anything. An Always On availability group failed over at 2 a.m. and won't come back clean. A migration stalls because the vendor is certain it's the database and the database is certain it's the vendor. A pharmaceutical plant needs its cluster to never drop a transaction; a growing app needs its encryption moved without a minute of downtime. Different clients, same shape: systems people depend on, where "it's slow" or "it's down" is measured in real money.
Fewer surprises and faster root-cause — and judgment you can trust with production. You're not paying someone to learn on your live system; you're paying for the experience to keep it secure, keep it available, and make it faster without breaking what already works.
Diagnosis before prescription
Most database problems aren't unsolvable — they're misdiagnosed. The tempting move is to act: add an index, bump the hardware, restart the service, and hope. That usually buys a day and hides the real cause. So before I change anything, I reproduce it, measure it, and find the actual bottleneck — the wait statistics, the execution plan, the version store quietly filling, the one statistic that went stale. Only then do I prescribe.
The second half matters as much as the first: I try to leave a system easier to support than I found it. That means documentation a future on-call person can actually follow, a runbook for the failover, and an explanation in plain language for the people who own the business but not the database. Clear communication isn't a soft skill here — it's how the fix survives after I'm gone.
Four doorways into the same head
Away from the keyboard I read and write about a few things that look nothing like databases and turn out to be the same reflex: understand the system before you move a piece. Here's the honest version of why they live on a consulting site.
Chess
I don't memorize openings — I want to know why the Ruy Lopez has pressured Black for centuries. It's pattern recognition, thinking several moves ahead, and spotting when a winning position is actually a trap. So is most performance tuning.
Philosophy
The Stoics and the old Greek arguments are practice for judgment under pressure — separating what you control from what you don't. That's a useful frame at 2 a.m. with an outage clock running and everyone watching.
Astronomy
The night sky over St. Cloud is a lesson in patience and precision. The light from Betelgeuse left it centuries ago — you can't rush something on that timescale, only measure it carefully and get the details right.
The fourth doorway is the writing itself — turning what I've learned into pages clear enough for someone else to use. If that instinct looks familiar, it's the same one that writes a good runbook. Wander through the interests if you're curious.
The interests are the evidence, not the distraction
If you're evaluating me for a database problem, everything above is one person: sustained attention, diagnosis before prescription, honest sources, and writing you can follow. The person who'll find your bottleneck is the one who finished the Caro-Kann guide. If that's the kind of DBA you want on the problem, let's talk.