Stop Refreshing Databases Like It's 1995
A quick guide to using SQL Server database snapshots so you can stop wasting time and start looking like a genius.
We all have blindspots in our professions, and they’re not just annoying—they’re baked into the system.
The Industrial Revolution gave us the brilliant idea that dividing labor into tiny, specialized chunks would make us all wildly efficient. And it worked.
But there was a catch: when you only see your little piece of the puzzle, you don’t realize there’s a whole puzzle.
Today we have the same setup.
Finance stays in its lane, sales does its thing, and IT is split into teams like networking, storage, and applications.
Everyone’s a cog in their specific wheel. The problem? Blindspots.
For example, developers often miss the brilliance of database snapshots because they’ve never been in a DBA’s shoes. They keep refreshing databases like they're rewinding VHS tapes, blissfully unaware they're living in the age of streaming. Specialization gives us focus, but it also makes us dumb in surprising ways.
In this article, I’m going to give you the tools to set up, use, and discard database snapshots like a pro.
But first, a quick story on when db snapshots are better than refreshes…
Once upon a time, I worked as a software developer on a team that thought it was totally normal to request a full database refresh multiple times per day on a 1 TB database. Yes, every. Single. Day. Here’s how that glorious workflow looked:
Developer tweaks some code in the test environment. Feeling confident.
Said developer tests the code, which, of course, modifies the pristine copy of the 1 TB production database.
Code fails spectacularly, leaving the test database riddled with garbage data.
Developer throws up their hands, opens a ticket with the DBA, and politely says, “Fix it!”
The test environment goes down for an hour while the DBA does their database-refresh magic. Developer grabs a coffee, takes a smoke break, or contemplates a career in gardening.
Rinse and repeat—every. Single. Day.
It’s a workflow so inefficient, you’d think it was designed by your competition. Let me show you how snapshots can save you from this endless loop of pain and wasted time.
Here’s what the workflow should look like if you’re using SQL Server database snapshots:
Developer tweaks some code in the test environment. Still feeling confident, because optimism dies hard.
Before running the code, the developer creates a database snapshot. (This takes seconds, not hours. Magic!)
Developer runs the code. Predictably, it explodes, corrupting the database with garbage data, because that’s what testing is for.
Instead of calling the DBA for a refresh and pretending to be polite, the developer just reverts to the snapshot. No tickets, no downtime, no awkward “thanks for fixing this again” emails.
Test environment is immediately restored to its pristine state, and the developer is back at work breaking things in less time than it takes to microwave leftovers.
Repeat as needed, while feeling smugly efficient.
With snapshots, you go from a multi-hour loop of frustration to a process so quick and easy you’ll have time to grab lunch, work out, or just stare out the window and wonder why you didn’t do this sooner. It’s like having an "undo" button for your database, and honestly, who doesn’t love a good undo button?
Now, I could stretch this article out and walk you through every tiny step of setting up and using snapshots. Instead, I’m going to link you to two YouTube videos that will make you look like you’ve been using snapshots your whole life.
The first video covers the grunt work of setting up a snapshot. Fair warning, though: the guy in the video confidently claims that if you take a snapshot of a 10 GB database, the snapshot itself will also be 10 GB. That’s wrong. Dead wrong. A snapshot takes zero space initially. It only starts using space when the original database is modified. To figure out how much space your snapshot is using, just check the drive the snapshot is in (Hint: it’s in the same drive as the original database).
The second video dives into the architecture behind snapshots and explains how this wizardry actually works. Watch them both, and you’ll not only set up snapshots like a champ, but you’ll also be able to impress your coworkers by casually correcting the first guy’s mistake. You’re welcome.
Video 1 (Setup):
Video 2 (Architecture):