Hi Yoel - I enjoyed your article on blob compression - but I believe there is a bug in the compression function...

I was starting to work on the same concept (as well as blob encryption) when I came across your article.  I started playing with your code using the sort of data that I have been intending on compressing.  I had noticed that for most of my data, I wasn't getting the kind of compression ratios that I was expecting, and in many cases the resulting compressed data was actually 2x larger.  This seemed to be the case for our smaller blobs (around 2K to 6K bytes) - which is the majority of the data that we are looking to compress (some rows contain much larger data, too).  I compared this with the same data, that I compress from a file using the same deflate method in a standalone .net program and got 80% compression or so.

I determined that the cause of the problem is that the blobData.Length (the length of the byte array) value is not reliable - it didn't actually match the length of the blob data.  It was often 6-8K when the actual data was much smaller, even zero length.  If I use blob.Length (the length of the SqlBytes parameter) when writing to the compression stream, I got the results I expected.

Just wanted to let you and the readers know what I found... please validate as you see fit

Oh, BTW - We are thinking about using blob compression to reduce our SAN chargeback costs (which are insanely high) - the blob data we're compressing needs to be online with the active data in our application,  but isn't updated after it's inserted, and isn't selected very often relative to the rest of the data; so the compute costs are manageble.