There are many reasons why one would consider hiring a professional database administrator (DBA). You may be concerned about user experience issues such as errors or slowness, or possibly backend items like backups, security or stability. If your database is hosted on a SQL Server, eventually you will run into issues that you cannot solve without the assistance of someone who has a deep knowledge of this platform.

End users rarely call to tell you that the application is running great, but in my experience, relying on users to report errors and slowness simply does not work. They tend to (at least in my case) report only a small fraction of errors. The first step in deciding whether or not to hire a DBA is to look at metrics (errors and excessive latency in my case). If you are not a DBA, you probably don’t have the knowledge to look deep into the database internals and make a sense of what you find.

I would suggest starting out with a high-level approach by using the application to measure and record all database errors and latency. This can be done by the developer and should take minimal coding. Developers need to be proactive and build error and latency tracking into their apps. All modern programming languages have the concept of a try-catch block, using this block, the developer can trap database errors such as SQL timeouts and deadlocks if you don’t have a monitoring tool in place. The developer can re-use the same basic code and wrap all database calling functions with error reporting code. You may also consider adding an instant alert when errors occur, this could be in the form of an email or SMS message. I particularly like this method, as it immediately lets me know if there is a major issue.

At some point, you will know that you have performance issues, but you may not understand how to solve them and keep your customers happy. A DBA understands your database in much more detail that you can imagine, knowing when you need a DBA is critical. Your team may be highly skilled but may not understand how indexes work, for example, or how much memory should be assigned to the instance.

I would say that it is time to hire a DBA when your own progress (as a developer) towards eliminating errors and reducing latency starts to slow. I use the word “starts” intentionally, as you don’t want to wait until you’re at a dead standstill with progress. Hire or outsource your DBA early, make your users and customers happier right now and save your precious time.

A SQL Server instance is more than just the place where the data goes. You must also understand security, high-availability, and what to do when things go wrong. A DBA is the best person to rely on to make sure that your data is always available, secure, and is not the bottleneck in your application.

My advice – If you’re not a DBA, don’t try to be a DBA.