October 4, 2013 at 8:55 am
We have around 10 people in development and one DBA [me] but the real question is how many DBAs take care of how many database/servers? We have around 130 servers with SQL and my last guess was around 700 databases.
October 4, 2013 at 9:21 am
One DBA (me) supporting one developer (me) servicing around 30 users, running 3 servers. Yes, I'm up to *** in alligators.
October 4, 2013 at 9:22 am
Nice topic, Steve, and I have to say I'm not at all surprised at the numbers people are reporting.
An interesting related question - for those that are "development dba's" or "database developers" (whatever you want to call it - a person that focuses on db design and software development primarily in the db itself, maybe with some DAL and ETL work thrown in), what ratios have you seen? For me, it's usually 1 database specialist per about 10-20 people (although I have been the db specialist on a small team of 5 before).
October 4, 2013 at 9:31 am
We're about 15:1 (Dev&QA/Dedicated DBA) 75:5
Breaking it down further (although everyone pitches in):
1 - Architect
2 - Admin/Performance DBAs
2 - BI/ETL Designers
We do train our devs and QA to handle basic admin of their own environments.
I find that the number of concurrent projects is more challenging than simple numbers. 1 DBA can easily handle a large team (25) working a single product. We see challenges with (25) if they're on multiple teams and schedules collide.
October 4, 2013 at 9:33 am
I was the accidental DBA and the developer at my last job, so 1:1.
At my current job it's 1:7.
October 4, 2013 at 10:55 am
The relationship to developers is an interesting one, my experience has been in vendor software shops and IT departments.
In the vendor development shop (mostly application maintenance vs. new product development) there was typically one DBA per team (19 teams) unless it was under 4 developers, that dba relied on the internal technical support desk for the IT administration and tier 2+ DBA support. The internal technical support team also had DA for pure database and schema design. This was a effective and very efficient model, the teams felt 'held up' but the schemas and performance were excellent, very important when those structures are heading out to clients.
In the IT shops the ratio has been much lower because your business needs to have at least 1 (if you're the only developer/tech resource in a production IT shop then you're a DBA first). Currently we primarily outsource development so every external developer is a DBA and running in a similar mode to the general comments in this thread. From inside our walls I'm the DA and we have an in-house DBA to handle our database requirements (operations, tuning, backup and recovery) so our internal ratio is 1:2
IMHO a ratio of over 1:10 is likely not considering the DBA responsibilities that are being assumed by some of the development staff. If those developers are designing and implementing schema, backing up or restoring databases then you have a good portion of a DBA FTE floating around there - be careful, in my experience most developers don't get data.
October 4, 2013 at 11:15 am
I am currently the only Architect/DBA, supporting 6 full time developers. We will also contract 1-3 developers here and there for focused work, so the ratio ranges from 1:6 to 1:9. But, I also have several analysts that can use direct access to the databases and could potentially write a painful query...
October 4, 2013 at 12:58 pm
My experience isn't one you want to use.. GRIN
As a consultant, I worked on teams that were typically pretty small, no more than 5-10 people. Not once did we have a DBA involved. These were SQL Server projects. We were involved in development work.
We also did work for an engineering firm that used Filenet. They had Oracle DBAs, but we did not provide that experience at all. Our team was typically 1-2 people.
I also worked for two development firms. In one of them we had 6 developers, all of whom did their own DBA work, but it was with a DBase style database. The other was a SQL Server database, with one Cobol developer, three VB developers, and one QA member. Again, no DBA, but one developer "owned' that responsibility. He was clearly qualified to play that role.
In my current role development is not done internally. We purchase software. We have no official DBAs, but one who "supports" Oracle, and then I support approximately 40 separate SQL Server production database instances. There is a slightly smaller count of test systems. My role is an Analyst, though, so technically speaking, we have no real DBA.
I have to think that either I have had a lot of bad luck in positions, or hopefully, I have been able to play multiple roles well enough that the choice has been made to save the money. Either way, I truly hope my experience is unusual, but I fear it is not.
Dave
October 4, 2013 at 1:00 pm
louie1487 78804 (10/4/2013)
I'm a developer that asked for my own server instance. Since I have sysadmin rights to it, I guess I am my own dba. Lol. 1:1?
The correct ratio would be something like these.
0.5:.05
0.6:0.4
0.7:0.3
1:1 implies there is one of you, and another distinct individual as a DBA.
Dave
October 4, 2013 at 4:14 pm
dtinney (10/4/2013)
...be careful, in my experience most developers don't get data.
I agree. Even as a developer. Having said that, my participation here perhaps sets me apart from the worst of the crowd 😉
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 4, 2013 at 4:57 pm
There are so many variables, I don't know how you could qualify a "good" ratio of Developers to DBAs. DBA can mean a lot of different things. If you have a few small (<10GB) databases in a small shop with not much change happening, then a decent "jack of all trades" can usually cover the jobs of DBA and developer as well as server admin.
I think you have to base the number of DBAs on the number of servers/databases/sizes that you have. Once you get past 100GB of data in the databases, you really need a dedicated DBA, unless you have 1 large database that you don't change much. Of course, if you have a dozen servers with a dozen 1-2GB databases on them, that requires more time to manage. I think that SQL Server out-of-the-box works great until your databases grow to over 10GB. That seems to be a good general benchmark of when you start seeing performance issues that you just can't keep throwing hardware at to make it work better.
Also, if you are in an industry with compliance issues, you might be at risk if your "DBA" is busy tweaking style-sheets. A lot of people call themselves "DBAs", right up until that dusty box in the corner that the vendor set up starts having issues. As the company grows, so does the databases. A good developer can usually put together a fairly good data model and create some useful indexes, but, eventually, you will have performance issues that will not heal themselves. When was the last time you tried to restore a backup, just to be sure it's working correctly? How long since you last refreshed your dev environment? What about upgrades? What about High Availability? What about security? All that data is kind of useless unless you create some good reports and/or dashboards that you can actually make some business decisions about. Considering a data warehouse?
Of course, then, as the IS department grows, is everyone following the same master plan, if there is one? From what I've seen, you don't always get instant "synergy" when you start adding more cooks to the kitchen. Our IS group of 9 people gets a lot more done than the last group of 60-70 could do because we don't bury ourselves in "process", we don't have anyone on the team that wants to stand in the way of progress because they are scared of what is unknown, and we don't have anyone doing the over-promise/under-deliver stuff. It's nice to be the one-man IS/IT department, but you have to know your own limitations. I think most of us in IS/IT have a bad combination of megalomania and poor estimating skills. It's easy to get cocky when you create an index that improves performance by 1000%, but then you might have another emotion altogether when someone asks you to recover some lost data!
October 4, 2013 at 5:35 pm
Here and now it is about 1:15 as far as developers to DBA's but that does not include GIS staff who present other challenges unique to their science. In times past it has been both higher ration and lower.
But is not a DBA who writes complex SQL processes, scripts, and procedures a developer as well? Worth a thought!
Not all gray hairs are Dinosaurs!
October 5, 2013 at 2:39 pm
John Mitchell-245523 (10/4/2013)
Two DBAs to about 19 developers. And they insist we handle stuff like backups and restores on development servers for them, "because the DBAs have always done that for us". I said yeah, my mum always used to do my washing, until I grew up and started doing it myself.John
Heh... you have to trust me on this... You DON'T actually want them to do their own backups. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2013 at 2:50 pm
1:5 for me not including any end user involvement or "Client Data Architects" or Project Managers or BA's or Managers or anyone from NetOps any offsite consultants or any of the vendors or...
Sometimes I actually get to do DBA stuff. 😀 Fortunately, I automated most of the critical stuff including some handy morning "job" reports, my own flavor of automated backups, some disk usage reports, and some "high usage" reports to automatically find troublesome code, etc, etc, a long time ago.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 6, 2013 at 8:49 pm
The last place I worked for that had in house development and hosting was about 1 to 8. It was a strange mix as one system had two developers and one DBA, the other had two DBAs and about 30 developers. But DBA definition is critical in this one.
We had three people who were called DBAs and had DBA in their title but did no monitoring, no tuning, had no backup responsibility. All they did was some TSQL to collect data or fix TSQL application bugs. It drove me nuts as a former DBA and now BA/PM as their code was all spaghetti, did not know how to tune (just add an index!) and I couldn't even get them to do code formatting for readability. But these guys had been around for 15 or more years so all I could tell management is they are in job protection mode. After them making system changes that made everything crawl after adding several new indices that weren't being used (apart from where they added index hints) and one column that had around 15 indices on it I finally got any *new* code they were deploying over to the DBAs I trusted to tweak, tune and standardise.
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply