SQL Server Best Practices: A Practitioner’s Guide

Written by Mike Walsh

March 17, 2026

Changelog: March 2026 – Initial publication

This is a living document. Next up:

Security Best Practices
Performance Best Practices

SQL Server Best Practices are not Universal

Aside from maybe autoshrink, not all SQL Server “best practices” are always applicable to all. But some are. And we find them misconfigured on almost every new server we touch. After 15 years of managing SQL Server environments and running SQL Server health checks for hundreds of companies, the pattern is always the same: memory wide open, backups unverified, tempdb still on one file, everyone is SA (and all of the other server roles), and someone almost always saying, “it’s been running fine…” It usually has been. Until it stops. We’d honestly rather you find and fix this stuff yourself than ever need to hire us for the basics, so we built free tools to help you check, and we wrote this guide to explain what matters and why.

Check Your SQL Server Best Practices For Free

We don’t just write and help clients implement best practices; we build and maintain open-source community tools to help you check your own best practices in your SQL Servers. You can get any of these tools for free at the GitHub link referenced in each post. No e-mail needed, no phone home, no charge. Just check out the posts, use the tool, and follow the links for the findings in each, and you’ll be ahead of the game.

sp_checkSecurity – Scans your instances for security vulnerabilities: elevated permissions, weak SA configurations, missing security patches, linked server exposures, and 40+ other checks.

sp_checkBackup — Reviews your backup history for recoverability issues: broken backup chains, missing backups, RPO violations, and backups without checksum verification.

sp_checkTempdb — Examines tempdb configuration and current usage: misconfigured files, uneven growth rates, contention detection, storage latency.

sp_checkAG — Analyzes your Availability Groups for availability issues: expiring certificates, timeout misconfigurations, high latency, and replica health.

Coming later this year:

sp_checkActivity – A lightweight way to see what is happening on your SQL Server with fewer parameters to remember and a lot fewer resources needed to run when you really need to see what is going on on your server for blocking, activity, and quickly find the pain points. We still love and use the other tools we link to below, but when time counts – we use this internally today I can’t wait for it to be available for all.
sp_checkHealth – This will encompass some of the checks above that are released, but a lot more that aren’t there – all of the things we care about when we check the health of an instance, but without going in-depth into things that we already have other tools to dive into or don’t matter for core health reviews. A health check in a single script.

We also love and use many of the free SQL Server community tools, and this post from a few years ago is still full of great ones to check out.

SQL Server DBA Best Practices We Wish You Already Knew

Verify Your Backups Are Actually Restorable. Having backups is not the same as having recoverable backups. Broken backup chains, split paths, missing log backups — we find these constantly. Test your restores.
Take Care of your SQL Server Maintenance. Now, look, a lot of folks will scoff at the idea of using a maintenance plan – I get that there are truly better ways to handle it – but I would LOVE to see more folks coming to us using well-set-up maintenance plans than coming to us with key missing maintenance. We love the Ola Hallengren scripts for this and have blogged extensively about best practices for them. But this guide for setting it up from a Jr. DBA’s perspective is a great start.
Speaking Of Maintenance – REALLY MAKE SURE YOUR BACKUPS ARE GOOD. Start with our post on sp_checkbackup, read the above-linked, really old post about the importance of restores, and be a paranoid DBA and make sure your backups are good. All else is secondary. And read this post from Jeff and avoid these common backup mistakes.
Check your Database’s Integrity (Look for corruption). This is also maintenance, but, like backups, it’s worth a separate callout. I hate the call from a client who has corruption but never read my long post about Corruption Resistant Backup Strategies and never has done a CheckDB.
Set Max Memory — It’s Not Optional. The default lets SQL Server consume nearly all available RAM. Leave 10-20% for the OS. This is still a top finding in our health checks.
Configure TempDB Properly. Multiple equally-sized data files, fixed growth rates of at least 64MB, and separate storage from your user databases. It has gotten better with the newer versions of SQL Server, but we see this wrong so often that we built an entire tool for it.
Enable Instant File Initialization. Without it, every data file growth event zero-fills the new space, stalling your workload. It’s a simple OS-level permission change that eliminates unnecessary waits on data file growth. (Log files don’t have this feature – so right-size your log files from the start.)
Don’t Ignore Security — Lock Down SA and Review Permissions. SA should be disabled or renamed. Logins should use AD groups, not individual accounts. Elevated permissions should be intentional, not leftover from an install 8 years ago. Use sp_checkSecurity to get a head start here.
Stop Using Balanced Power Mode Already! This is robbing you of performance and has been talked about quite a lot.

Best Practices for Virtualizing SQL Servers

Most SQL Servers that aren’t in the cloud are running in a VM of some sort these days. It used to be predominantly VMware, but thanks to Broadcom and their licensing play, we’re seeing a little more Hyper-V out there. We wrote a best practice guide for each of these so you can take some guesswork out of the setup.

Note on other virtualization platforms: I’ll just say it outright: I’ve not seen a really well-performing hyperconverged SQL Server environment yet, so your performance mileage will vary if you get bought into another vendor’s sales tricks and go all hyperconverged. We’ve made a lot of money because of hyperconverged architecture.

And we’re starting to see more folks consider open-source platforms, like Proxmox. The jury is still out on those in my mind for a few reasons:

Some grey area may exist for official supportability and even licensing, according to some conversations I’ve seen on LinkedIn.
When and if an issue arises – and you are on one of these untested platforms – you are now betting your entire environment on something Microsoft support will likely give you best effort support for at best, or maybe even say “once you recreate that on physical hardware or a supported virtualization platform, we’ll help you out.”

So why bet your farm on an unsupported VM platform for a licensed database server?Just go with Hyper-V or head to the cloud if you want to get off the other provider.

Hyper-V and SQL Server Best Practices – These are the things we see most folks tripping up on with their SQL Servers on Hyper-V. Check out our best practices and start right.
VMware and SQL Server Best Practices – Virtualization isn’t the problem; it’s not following the best practices from the start.

SQL Server Upgrade & Migration Best Practices

Most folks who stay at one DBA job for a while don’t get to do a ton of these in their careers, especially given how slow most companies seem to be to upgrade these days. The first best practice here, frankly, is to get upgrading. (We will have a lot of content coming up in April about Upgrading SQL Server, since the SQL Server 2016 end of life is fast approaching in July of this year.)

If you’re still on SQL Server 2012, 2014, 2016, and even 2017, it’s time. But an upgrade done wrong is worse than staying put.
Our strong opinion: migration-based upgrades over in-place upgrades. Always.
Use CNAMEs/aliases so your next migration is easier than this one.
Plan to fail – have a rollback plan before you start.

While we refresh our upgrade content, this post about migration considerations from a junior DBA’s perspective is a great place to start

This older webinar series on SQL Server upgrades is still very much applicable, and I covered the phases from considering to planning to executing, with links and info here for you to plan and execute your own upgrades.

Learn With Our Case of the Week

Each Friday, we try to post a SQL Server case of the week – something we helped a client figure out. These posts can give you some good overviews of how to troubleshoot and some ideas of how to use these best practices, tips, and tools in your own environment. And maybe help you avoid a similar issue.

If you came here looking for a specific SQL Server best practice, leave a note in the comments. We’ll work it into future updates to this hub and build practical checklists around it.