When is it worth getting a DBA?

I've now worked at a few tech companies ranging from 10 people to ~150 and I've never encountered a real DBA. How big does a company need to get before it merits getting a DBA? What are the criteria that need to be met?

(I also posted this on Stack Overflow. It's only in both places because a moderator there suggested, "This might be one of those rare cases where it's worth it to ask on both SO and SF")

Solution 1:

For a lot of companies they simply don't need a full time DBA, even if they have an inhouse database that is home built. Others need several DBAs.

As one person mentioned when the cost of losing the database is more than the salary of the DBA, then get one. That's a very good place to start. However if the database doesn't change that much, and it's on good hardware a company could probably get by for years without a full time DBA. The trick here is to have a good local (or remote) consultant to handle making sure that backups are automated and that the other database maintenance is happening on a regular basis. Have them check the system a few times a year for a health checkup and hire them to handle large projects and server upgrades and you should be fine for the most part.

As the company grows you'll end up with a more junior level guy in place to handle the more day to day stuff, but keep the consultant around if needed until it becomes worth while to pay the price for a senior level DBA.

There's no size company that needs a DBA. The company I'm at now is a small 20 person company, but we live and die by our database so hiring a senior level DBA made sense. I've got side project clients which are hundred person companies that only have an order processing system in house where the database rarely changes. I upgraded the server in 2007 and haven't been back since. I check in every few months and I'm told that the system is humming along nicely and it's backing it self up so I go on my merry way.

Solution 2:

If you are only using third-party software, I would say that it depends on the RDBMS that you will be using (Oracle, mySQL, DB2, MS SQL, etc.), the size of the data relative to the power of the hardware it will be stored on and the quality of the third party software. For small things on easy-to-use databases, having a (willing) tech guy do the basics is probably sufficient. OTOH, drafting a developer who wants to write web code and forcing her to do backup Oracle databases is a bad idea.

If you are doing in-house development, I would inquire as to what the scaling requirements of the database are (are you building the next google or twitter, or are you keeping recipes?). What you want the DBA to do (backup the databases? secure the databases? Participate in development? Write code? Architect database schema? Work on scale-up or scale-out? Create a replication scheme? Interact with hardware vendors? Specify hardware? Create "coding standards"? Just herd the cats?).

Bringing a DBA in early can help prevent projects from running into trouble later, and it's generally cheaper to avoid common mistakes now than to fix them later.

Solution 3:

I would say it depends.

Since this is a business, ask yourself, "What's the cost of losing this database?"

As soon as the cost is greater than or equal to the salary of a DBA, hire a DBA.

The "cost" will be a difficult number to come by. But it should include, recovery time, lost productivity (per user), and lost sales. Places like Amazon (who peaked a few years ago at 60 sales per second) can put a definite number on their downtime cost.

Solution 4:

Once you have a DB server and begin experiencing performance issues, that is the time to get a DBA, IMO. There may be times where developers have enough experience to handle an initial DB configuration in some cases.