I started my DBA career before Google became a verb and before Stack Overflow existed. Before you could just search for an error message and find the answer in thirty seconds. If you hit a problem, you read the manual, called Microsoft support, or figured it out yourself. That kind of environment makes you think differently about problems, and I think it still matters today.
Here are the things I’ve learned across 25 years of working with databases that no certification teaches you.
1. The database is never just the database
Early on I thought my job was SQL Server. Queries, indexes, backups, jobs. Clean and simple. It took me years to realise that the database sits at the centre of almost every problem in the business. Slow application? Probably the database. Bad report? Data quality issue — in the database. Compliance audit? Auditors want the database logs.
DBAs who stay siloed in their own technology get bypassed. The ones who understand the whole system — the application, the network, the storage, the business process — are the ones people call when something really goes wrong.
2. Performance tuning is 80% reading and 20% fixing
Junior DBAs want to jump straight to adding indexes. I understand it — it feels productive. But the best tuning work I’ve done started with sitting with execution plans, wait stats, and Query Store data for a long time before touching anything. I want to understand what the engine is actually doing before I tell it to do something different.
Most of the outages I’ve caused were times I moved too fast. Slow down, diagnose properly, then act. An old carpenter I knew had a saying: “Measure twice, cut once.” Same applies here.
3. Documentation you write today saves you at 2am in three years
Nobody wants to hear this. But I’ve been saved more times than I can count by a comment in a stored procedure, a note in a runbook, or a README I wrote on a quiet Friday afternoon. I’ve also spent miserable hours reverse-engineering something I built myself and completely forgot about.
Write it down. Even rough notes. Future you will be grateful.
4. Trust your instincts, but verify them
After enough years you develop a feel for it. You walk into an incident and something just seems off — the wait stats don’t match the complaint, the query plan looks wrong for the data volume, something isn’t adding up. That instinct is real and worth paying attention to.
But verify it with data before you act. The most dangerous DBA is the one who’s experienced enough to be confident but not careful enough to check. I’ve been that DBA. It doesn’t end well.
5. Relationships matter more than you think
The best thing that happened to my career was building decent working relationships with developers, sysadmins, and business analysts. Not because it made the job more pleasant — though it did — but because it gave me early warning on everything. New projects before they hit production, architecture decisions before they were made, and a proper understanding of what the business actually needed rather than what the ticket said.
If you only talk to other DBAs, you’re missing a lot.
6. AI is a tool, not a replacement
A lot of DBAs are either dismissing AI entirely or worrying about it. Neither seems right to me. It’s genuinely useful for boilerplate queries, suggesting index candidates, explaining unfamiliar syntax. It saves time on routine work. I use it.
What it doesn’t have is context. It doesn’t know that your most critical stored procedure was written a specific way because of an audit requirement from years ago. It doesn’t know that your storage has a latency quirk that makes certain query patterns perform worse than the execution plan suggests. It doesn’t know what went badly wrong last time and what you learned from it.
That context is what you bring. Nobody can automate 25 years of hard-won experience — not yet anyway.
25 years goes fast. SQL Server 7.0 was new when I started and the technology has changed beyond what I thought was possible back then, but the fundamentals haven’t.
Seriously.