At what point should a company think about employing a specialist DBA? How big would they tend to be, how critical do those servers need to be?
I think that you ought to hire one on a consulting basis as you are building software, or setting up servers. They can help ensure that you build a strong design or don't make mistakes as you get started.
If you find yourself hiring a consultant more than a week a month, it might be time to consider hiring someone full time, and perhaps letting them handle other tasks on the side.
I think that's largely a business decision. How important is your data to the company? The more important it is, the more it might behoove you to have someone who knows how best to protect it. You don't have to hire a DBA full time right out of the gate. You can take advantage of services or consultants that can bring a full set of knowledge to bear on your system for shorter periods of time. I'm not sure that the size of the database has any bearing on whether or not you should have someone on full time. I've seen quite small databases that were poorly designed or had poorly built code running against them that needed a lot of hands on support. I've seen well designed databases in the 200-500gb range that needed the barest of maintenance routines to stay running 24/7 without the need for any DBA attention at all.
In short, the amount of pain you'll experience if your database slows down or goes offline should be the measure of how much you'll be willing to spend to get a DBA into the office, full time or part time.
I think it also depends on what type of DBA you need, or to put it a better way, what kind of work they will be doing. Any business doing development work against SQL, will use a 'development' DBA different than how a business with off-the-shelf software that runs against SQL, will use a DBA. In those cases, gut-feel tells me that dev shops need DBA experience a lot sooner than non-dev shops.
No one has followed this question yet.