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")
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.
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.
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.
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.
Depending on the resources and time spent to manage the database, what is the concern and where the database is housed. A lot of companies decide it is more cost effective and reliable to partner with a managed hosting provider who offers database services then to higher a DBA who may be idle for most of the day and used as an insurance of 'what if'.
This really depends on how many Databases that you have to manage. We have an onsite DBA, and he is very good. We have PROD/TEST/TRAIN/DEV Oracle Instances which require frequent security patching, regular patchings and upgrades after regression test cycles from the functional side. Outside of this, anything else in the company that uses an Oracle or SQL database he also manages. He is tasked with keeping updated clones for testing, and he also Manages the RMAN database backups from within Enterprise Manager.
Considering our Database is the lifeblood of the company, I think in certain situations you must have a skilled DBA on staff.
Whether or not you need to hire a DBA, you need to have someone in charge of the production and development servers.
You need to have a certain person in charge of Production changes.
On large projects with more than 2 developers, you need to have a person in charge of migrating changes into development (from workstation or user schemas).
If you plan on using Reporting Services or Analysis services you might look into a DBA which specializes in those technologies.
If you have sensitive data, you better make sure someone is watching over it and has proper security in place - or else you may run afoul of gov regulations, which costs money.
When
I would suggest that as soon as databases start taking up enough of your time that you can't get your work done, you might consider it.
Try to get a DBA with a multi-discipline background, so that they have something to do besides sit around and wait on the DB to break.
I'm not convinced that DBAs are needed at all.
As an application developer, I think that a DBA is unnecessary - any application-side modifications should be done by the application developers - a DBA neither could nor should make such changes (indeed, those changes should need to go through the same change control and QA as any other change from the development team, so the DBA would become one of the team).
Likewise, anything which is NOT a change in the application is a sysadmin issue and should be handled by the operations team with THEIR change control policy - again not DBA territory.
When I find out what one is good for, I'll let you know.
In my opinion, DBAs can't really do much performance work, because 99% of that is going to come from modifying the application, which operations should not be doing.
Probably at around the same time in the admin cycle that it's worth getting a Sys Admin rather than have some one do that part time as well as their real work.
Sure that's partly a flippant answer, but only one that's intended to make you think, you need a sys admin generally for managing security, availability and performance of your back-end systems. You'll need a dba to manage the security, availability and performance of your database systems. In either case the job is worth separating out when it starts taking too much time, becoming too tricky or otherwise consuming too much scarce resource.