We've used it in a few cases, for specialized aggregates or to split an object into rows, but we don't access tables from within any CLR code I've seen. In most cases we've used it to significantly improve performance, in a few to make code more readable and maintainable. In the latter case, with one specific aggregate, we've had mixed performance results - one line of CLR code vs a 40 element expression, for a small (<100000 say) data set no difference in performance, but for large ones SQL sometimes generates a slower plan using the CLR - so its treating native aggregates differently from CLR ones in some circumstances.