Data compression for tables and indexes are beneficial, especially for large tables within your SQL DB, where you are doing more read operations than writes. In Microsoft Dynamics AX you are advised to do this via the client, otherwise your settings would be lost during the Data Synchronization.

Unfortunately there is another case of hardcoded value from Microsoft, the SysSQLSetupHelper class is checking the version and the edition of SQL Server. Since Compression is a feature supported by version SQL Server 2008 (v10) and up, the code needs to be changed to cater for SQL 2012+ as per below:

public boolean isDataCompressionSupported()
{
    ResultSet   resultSet;
    str         sqlVersion;
    str         sqlEdition;
    boolean     ret = false;

    resultSet = this.sqlServerInit();
    sqlVersion = resultSet.getString(1);
    sqlEdition = resultSet.getString(2);

    //if(sqlVersion == '10.' &&
    if (match(@'^1[0-9]\.', sqlVersion)
        && (strStartsWith(sqlEdition,#SQLEDITION_ENTERPRISE)
            || strStartsWith(sqlEdition, #SQLEDITION_DEVELOPER)
            || strStartsWith(sqlEdition,#SQLEDITION_DATACENTER)))
    {
        ret = true;
    }
    
    return ret;
}

After the adjustments, you will be able to open the SysSQLSetup form in AX to carry out the compression changes. I would highly recommend the MSDN resources and articles below to determine for which tables and indexes is it safe or beneficial to turn on this feature.

In Production the general rule of thumb is to check ROW or PAGE compression improvements, make sure you have much more reads compared to write operations since there could be a write penalty for the latter one, and only do it for entries which have at least 100 pages of information.

It is safe to turn of PAGE compression in a Dev/Test/QA installation to save disk space, memory and potentially speed up your environment.

References: