Size versus features

Does the size of your database regulate the features?

I had some interesting discussions with some of the Microsoft folks at PASS last fall and I thought I'd share the content of one of them with you.

I was of course complaining about backup compression only being available for enterprise customers, and the discussion kind of just sprouted from there. And while I can present both sides of the argument, my side is really only needed here. Now, I know what you're going to say. I'm not giving them a fair shake by not presenting their side. But you can infer their side from my comments, and it doesn't matter anyway because I'm right.

They're basically saying that you don't need backup compression on non-enterprise SKUs because enterprise installations are pretty much the only ones big enough to really need it. OK, so I presented a little bit of their argument ... so sue me.

Well, I'm here to tell ya that the reasoning behind that is not only wrong, it's downright criminal. Just wait, my reasoning is sound.

For starters, there's no relation between size and features. Just because you have a lot of data doesn't mean that you need any of the advanced query or indexing features that come with enterprise. I may have a large DB that stores Web site clicks, and these clicks could be stacking up into the billions, but that doesn't mean that I need advanced functionality. I may only run simple queries against that data. And let's not forget either that Standard edition is pretty complete, and you can do a lot of pretty rich querying with it.

There's also the case of the archive DB. I may need to store tons of data that I hardly ever query, but I need it to be online. It would be nice to be able to compress those backups.

Now let's look at the other side of the market: the small side. There's a reason why vendors like Red-Gate and Idera made their bones in the SQL backup arena by covering the small end of the market -- because small shops need compressed backups too. See, your need for compression isn't guided by how much data you have, nor is it driven by how much income you have or the features you need. It's driven by the size of your backup media. And it's these smaller shops that have a lot less backup space, so they need the compression even more in a sense. And that's not really entirely accurate. The reason I say that is because while small shops feel that strain quite often, really large shops feel it as well. It actually moves with the size and need for your data recovery, right? What I mean by that is that even large shops that have HUGE databases have backup space problems because it's very expensive to buy the speed and amount of disk you need to house a 50TB backup. And if you go straight to tape, it's pretty expensive too.

Also, quite often the bulk of an enterprise's installs are Standard and not Enterprise edition. With departments being what they are, you often see a large company is functionally broken up into several smaller companies and the departments often don't even talk to each other. So the company as a whole can have some extensive backup space requirements, but it's broken up into dozens of smaller chunks. I know personally the bulk of the boxes in my company aren't Enterprise edition. And the bulk of my DBs aren't over 1TB. So what about all the rest of these DBs? If I use Katmai's backup compression on my Enterprise boxes, what will I do for the rest of my installs? I'll have to use a third-party tool like LiteSpeed or Red-Gate. And as long as I'm using those tools for the bulk of my boxes, I'd might as well put them on my Enterprise boxes and get the advantages afforded by those utilities. I'd hate to have to tell one of my VPs that I can't restore his table because we only use LiteSpeed on the non-Enterprise servers. You don't want to switch backup routines mid-stream. I've talked about all this before, so I'm going to go into too much detail here, but you get the idea.

Basically, you want a single backup routine in your company and you want everyone using it. This is why centralized data groups are important. Not only do they know what's going on everywhere, but they can make these big decisions and negotiate deals for bulk licenses and get an overall better deal. And data becomes more ubiquitous because it can be passed around where it needs to be and you know the other side will be able to work with it.

So no matter what anyone tells you, don't believe that your backups have anything to do with the size of your DB. You need either a shorter backup time, or you don't have enough disk space to house your backups. Those are the main requirements for deciding whether you need backup compression or not. And of course, the product you settle on is decided by the other features they offer.