Compression options:

1) FS

2) Sparse files

3) Prefix compression (indexes)

4) Better format (varlen, common header, null fields)

5) Column store

6) Block compression

7) Per-column compression

8) Row compression

9) WAL compression

10) New algorithms (LSM, BWTree, ...)

------------------------------

Postgres:

1) TOAST: https://www.postgresql.org/docs/10/static/storage-toast.html

2) WAL: https://www.pgcon.org/2016/schedule/attachments/432_WAL-Reduction.pdf

3) Plans: https://habr.com/company/postgrespro/blog/337180/

------------------------------

MySQL: 

1) Table Compression https://dev.mysql.com/doc/refman/5.7/en/innodb-compression-background.html

2) Page Compression https://mysqlserverteam.com/innodb-transparent-page-compression/

3) COMPRESS/UNCOMPRESS functions

4) Column compression (https://www.percona.com/doc/percona-server/LATEST/flexibility/compressed_columns.html)

"The code changes required to get the old InnoDB compression to work properly were extensive and complex. Its tentacles are everywhere—I think that just about every module inside InnoDB has had modifications done to it in order to make it work properly when compression is in use. This complexity has its challenges, both in terms of maintainability and when it comes to improving the feature. We have been debating internally about what we should do about this over the long run. As much as we would like to redesign and rewrite the entire old compression code, it is impractical. Therefore we are only fixing issues in the old compression code reported by customers. We think there are better ways to solve the underlying performance and compression problems around B-Trees. For example by adding support for other types of indexes e.g. LSM tree and/or BW-Tree or some variation of the two. "

------------------------------

MariaDB

?? 1) WAL compression

?? 2) ColumnStore format

?? 3) Independent Column Compression (similar to Percona?)

// TODO

------------------------------

SQL Server

1) Row compression - metadata, varlen for numeric types, trimming for CHAR types https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/row-compression-implementation?view=sql-server-2017

1.1) NULL and 0 take no bytes!

2) Page compression https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/page-compression-implementation?view=sql-server-2017

3) COMPRESS command https://docs.microsoft.com/en-us/sql/t-sql/functions/compress-transact-sql?view=sql-server-2017

------------------------------

Oracle

1) Basic compression - compression during bulk loads only (direct load, CREATE TABLE AS SELECT)

2) Advanced Row Compression (ex. OLTP Table Compression) - used for DML, keep data compressed in-memory; more CPU but less IO - reads gets gain anyway

3) Advanced LOB compression and deduplication - appears to be something similar to PG TOAST (?)

4) Index compression - just prefix compression

?? 5) Advanced Index Compression 

?? 6) Hybrid columnar compression (query level, archive level) - tremendous compression rates (up to 50x), 5-15x typical, "query" - improves scan performance, "archive" - for data archives

7) Compression at tablespace and table levels

8) Tablespace encryption - after compression, column encryption - before compression, no effect

9) Indexes are compressed separately from data!

10) Clustered tables - only prefix compression is applicable

11) Heat Map - insight on how data is accessed

12) Advanced Row Compression - can read specific attributes without full decompression

!!! https://blogs.oracle.com/dbstorage/updates-in-row-compressed-tables

"With Advanced Row Compression, when the block is full, it is compressed. More rows are then added (since more rows can now fit into the block), and the process of recompression is repeated several times until the rows in the block cannot be compressed further. Blocks are usually compressed and reformatted in their entirety, but, starting with Oracle Database 12c Release 2, in some cases the block can be partially compressed, hence resulting in CPU savings and extra compression."

------------------------------

MongoDB

1) Block compression (Snappy, zlib) https://docs.mongodb.com/manual/core/wiredtiger/#compression

2) Prefix compression (indexes, once per page) https://docs.mongodb.com/manual/reference/glossary/#term-prefix-compression

3) WAL compression https://docs.mongodb.com/manual/core/wiredtiger/#storage-wiredtiger-journal

4) Configurable per-collection and per-index

"The cache generally stores uncompressed changes (the exception is for very large documents). The default snappy compression is fairly straightforward: it gathers data up to a maximum of 32KB, compresses it, and if compression is successful, writes the block rounded up to the nearest 4KB.

The alternative zlib compression works a little differently: it will gather more data and compress enough to fill a 32KB block on disk. This is more CPU intensive but generally results in better compression ratios (independent of the inherent differences between snappy and zlib)."

—Michael Cahill