we have implemented SQL Compression on several sites now, and in every case the performance has improved (all sites were IO bound). We are starting to see some sites with a lot of SSDs, and these tend to be CPU bound, but SSDs aren't cheap, so the space saving (while impacting performance as it increases CPU workloads) is significant. On Xe and 8.0 systems we achieved around 70-80% reduction, on later releases with Unicode data and SQL 2008 or later we have seen reductions approaching 90% (best was 1.3TB to 150GB). There is no need to determine if row or page compression suits particular tables better, or even to exclude tables with a lot of updates from any compression (e.g. Next Numbers) - you can make everything Page Compressed and still come out ahead. Note that in an upgrade from an old release JDE will recreate a number of tables - uncompressed (F0911, and F42199 usually being some of the biggest)- as will the Unicode Conversion, so you may need a heap more space for an upgrade. Despite Unicode dramatically increasing space used for uncompressed data, a compressed Xe database before an upgrade and a compressed E910 database after should have a very similar size(just allow 10x the space to get through the upgrade itself!)