SQL Storage Compress vs Native SQL 2008 Compression

teschoen

At first blush I was impressed with the realitive ease and one 'click' configures all nature of SQL Storage Compress. However I have a handfull of mission critical databases that are 200GB+ each and taking the apps offline to do a full restore for compression isn't something I can take lightly. Also, these databases are replicated, and rebuilding the publication and subscriptions isn't appealing in the least.

I have been playing with SQL 2008 Page and Row compression and have found that for some of my data the compression is impressive, and it does indeed save on IO, however the configuration is a little more involved.

I can, however, compress a table during a lull in our activity and while performance is degraded the data is accessable.

Has anybody used both and would be able to provide a pro/con list of each solution?

I know Red-Gate software is normally top notch (I use many of their products daily) but is this product really worth $1,500 USD when SQL 2008 has compression built in (Yes I do use enterprise... so maybe that answers my question)

javen

Thanks for your post,

The two approaches differ in that SQL Server 2008 EE Page and Row Level Compression are applied on an object by object level and SQL Storage Compress compresses at the data file level. The file level approach can be much less complex to implement and manage. In your case SQL 2008 EE is a sunken cost, but for those customers who are not running Enterprise Edition, you would usually find the cost difference vs Enterprise Edition is far greater than the license cost for SQL Storage Compress.