TFS Database sizes for a somewhat more “normal” team

Brian Harry

I talk a lot about the DevDiv dogfood server.  The numbers are always astronomical and people’s heads spin when they see them and most people wonder what relevance it has to their life :)  I publish the DevDiv stuff for a variety of reasons.  I do it to show how scalable TFS is and that it is ready to handle almost anything you throw at it.  I also do it because I’m closest to that server – I use it all the time so it’s somewhat personal.

I think I’m going to start publishing information about other servers occasionally so that you can see what things looks like for a range of different teams/usage scenarios.  Today I’m going to write about a TFS server used by the AdCenter team.  It’s still a pretty big team with 1,384 users in the past 2 weeks but their development methodology and legacy are quite different from DevDiv.

The server is just over 3 years old – the first checkin was on 6/7/2006.  So you can think of these numbers as being relevant to about a 1,000 person team over 3 years.

The first difference that I notice with the AdCenter team is that they create a lot of smaller Team Projects compared to DevDiv.  We have just a handful of Team Projects – maybe 20.  They have over 300.

The relative sizes of databases still resembles DevDiv with Version Control being the lion’s share and most other things nearly irrelevant.  Looking at this, I’d say they do a lot of builds.

Here’s the top database sizes.  As you can see, it all adds up to about 350GB.  That’s a far cry from the DevDiv 15 TB.  It’s over 40X smaller even though the team size is only about 3X smaller.  Why is that?  Well, I’ve said that VS is a bit of a weird org in this respect for a long time.  For one thing, the code base goes back more than 20 years.  For another, we use a VERY heavily branched development methodology that really blows up the version control database.  It’s also a very connected code base resulting in the average developer needing hundreds of thousands of files in each workspace in order to build/debug their component.

Here’s the breakdown of the version control database.  As always, tbl_LocalVersion is a big chunk.  tbl_LabelEntry looks very large so they must have a practice of labeling every build and keeping those labels around.  The rest are all pretty small.

And here’s the numerical breakdown…

As you can see, not all TFS databases (even for large teams) need be mammoth.  Development process plays a huge role in the strain you place on your development server.  Sometime in the next month or two, I’ll find an even smaller server and one that is shared by many teams and you can see what those look like.

Brian

Brian Harry Corporate Vice President, Cloud Developer Services

Follow