Skip to content
← Back to blog
3 min read

Why I'm a PowerShell-first DBA

  • powershell
  • sql-server
  • philosophy

SSMS is great — for one server, one query, one change. The moment the job is "do this on every instance" or "do this on every instance that matches some condition," the GUI stops being a tool and starts being a tax.

The math is the argument

Say a routine task takes me 30 seconds in SSMS: connect, run, eyeball the result, move on. Multiply by 50 instances and that's 25 minutes of clicking — plus whatever attention tax I pay each time I context-switch between servers.

Now imagine I do that task twice a week. That's nearly an hour gone, every week, on something a script could do in seconds. Across a year it's days of work I'm choosing to keep doing by hand.

A loop is just cheaper:

$instances = Get-Content .\instances.txt
foreach ($instance in $instances) {
    Invoke-DbaQuery -SqlInstance $instance -Query "SELECT @@VERSION AS Version"
}

That's three lines. It scales from one instance to a thousand without changing.

The GUI lies — quietly

The other problem with the GUI isn't speed, it's trust. When I click around in SSMS, I'm relying on my eyes to notice when something's off. On the 47th instance of the morning, my eyes are not a reliable instrument.

A script doesn't get tired. It returns the same shape of data every time. I can pipe it into Where-Object, Group-Object, Export-Csv, or a comparison against yesterday's run. The output becomes data I can reason about, not a window I have to read.

What "PowerShell-first" actually means

It doesn't mean never opening SSMS. SSMS is still the best place to write and tune a single query. What it means is:

  • The default tool is a script, not a window.
  • The default scope is the farm, not one box. If a thing is worth doing on one server, it's worth being able to do on all of them.
  • The default output is data, not a screenshot. If I can't diff it, I can't trust it.

That mindset shift — from "where do I click" to "what does the loop look like" — is the whole game.

Where to start

If you're a DBA who hasn't made the jump yet, start small:

  1. Install dbatools. It's the PowerShell module for SQL Server, and it's astonishingly good.
  2. Pick one task you do every week. Just one. Script it.
  3. Run it on one instance. Then ten. Then your whole list.

You'll never go back. And on the day someone asks you to do something on every server in the farm by lunchtime, you'll already be done.