Reducing Operational Costs with SQL Enterprise
In a recent post, I talked about some of the people benefits of the Online Maintenance features of SQL Enterprise Edition. Today this is more about quantifying the cost savings of the SQL Enterprise Edition Data Compression feature by reducing storage and compute resources on VMs by 50% or more.
Customers can step up from Standard to Enterprise or from Server/CAL to Enterprise. Microsoft can offer generous grants towards the upgrade based on your current Server/CAL investments. During any cost justification exercise, we need to combine all factors including scale limits, performance improvements, flexible feature exploitation with an emphasis on immediate hard cost savings.
If you could reduce your SQL VM storage and memory by 50% or dramatically improve performance, what would that be worth to your company? Many of my customers have a cost associated with virtual machines. By looking at Enterprise Edition to enable compression in your databases, you can begin having meaningful conversations about the benefits and returns of SQL Enterprise Edition.
The image in this post is a PowerBi Dashboard that visualizes example savings on a 150GB SQL database running on a VM. By running the compression estimation script, you'll be able to determine this as well. In my case, it was over 60% compression savings. What this really means is that my storage footprint and Buffer Cache memory requirements can be reduced by more than half. Despite a single digit CPU overhead, my scans still ran in half the time as did backups and rebuilds. Physical I/O is particularly expensive in VMs so getting 2x more of your working set into memory can have tremendous performance benefits by reducing or eliminating physical reads. If performance is secondary to resource utilization, then the hard cost savings expressed to your IT leadership will be "half the storage, half the memory" in going to SQL Enterprise and enabling Data Compression.
The results of the estimator are just that; an estimate. Your mileage will vary based on the repeatability of your data and other demographics. If you are interested in learning more about how you can optimize your SQL Server environment through consolidation and the rich features of SQL Enterprise, contact your Microsoft reps.
There is always a catch depending how much the data has compressed, for example if there is 50% space savings in a table it could take twice amount of cpu to decompress the data and it can quickly create CPU bottleneck. Proper analysis need to be done by using both page and row compression, work load analysis and determining the read write factor on where compression can be applied in an OLTP system.
In my experience, compression wins because the performance benefits of reduced I/O far outweigh the small CPU overhead. I have had great results using it in both OLTP and DW environments.