Share

Save Space with Teradata: Utilizing Block Level Compression and Row Partitioning

Save Space with Teradata: Utilizing Block Level Compression and Row Partitioning
tune3

The latest generation of Teradata systems always has Block Level Compression (BLC) enabled. When using MultiValue compression, the compression factor is typically low.

How Block Level compression and MultiValue compression relate to each other is shown in detail in the article below:

https://letters.dwhpro.com/content/files/2026/05/teradata-multivalue-blocklevel-compression-mvc-blc.html


Want more practical data engineering analysis like this?

Join DWHPro Letters and get field-tested notes on Teradata, Snowflake, AI, migrations, performance, and enterprise data work. DWHPro Letters is free. Subscribe to get new issues by email.

Get the next issue


In this article, we will show you a trick on how to use Block Level compression together with Teradata Row Level Partitioning to save space.

To comprehend this, it is crucial to grasp the functioning of Block Level Compression and Row Partitioning.

BLC packs whole data blocks using different algorithms. These include ZLIB (software compression) and ELZS_H (hardware compression), used in 9 different compression levels.

Get the next issue by email.

BLC is not utilized for performance tuning due to the need to decompress data blocks in memory upon access. However, this article's focus is on space conservation.

BLC achieves better compression when equal values are grouped together in a data block. Consider a table with a date field and a unique primary index (UPI).

Due to the primary index distribution, date values will be distributed randomly across the AMPs without row partitioning. A UPI will distribute evenly across all AMPs.

Let's discuss how data in a Row Partitioned Table is distributed. Initially, the data is distributed to the AMPs based on the UPI. Following that, the rows are sorted into the designated partitions according to the partition expression.

For our example, we can base the partition expression on the date. The aim of Row Partitioning is to store rows with identical dates in the same partition. This ensures they are physically adjacent on the disk, enabling efficient access.

This means that better compression and space savings can be achieved simultaneously. The compression algorithms achieve higher compression rates because the date values are stored close together within the same data blocks.

In practice, ideal conditions can result in up to 50% smaller tables.

It is important to consider the overall design when utilizing row partitioning. While it may be appropriate for temporary tables, it should not be used solely for space-saving purposes on production tables.

In the future, should you encounter insufficient space again, it would be worthwhile to contemplate this alternative.


Planning or surviving an enterprise data platform migration?

I write regularly about the performance, cost, architecture, and project mistakes that show up in real Teradata, Snowflake, Databricks, and enterprise data work.

Subscribe for free and keep launch access.

Written by Roland Wenzlofsky, founder of DWHPro and author of Teradata Query Performance Tuning. DWHPro has helped data warehouse practitioners for 15+ years.

Subscribe to DWHPro Letters

Practical field notes on enterprise data engineering, production AI systems, platform migration, and the senior engineering market.
Written by Roland Wenzlofsky Founder of DWHPro Author of Teradata Query Performance Tuning
Get the next issue
Subscribe