Teradata

Parallel processing before it was ordinary

Cloud warehouses made distributed query processing familiar. Teradata was doing it decades earlier, and the architecture is the thing to understand first.

Data is divided across processing units. Each unit holds a portion and is responsible for it.

A query runs on all of them simultaneously, each working on its own data, and the results are combined.

The consequence is that a single large query uses the whole system rather than one processor. This is why the platform handled analytical workloads at scales that were difficult elsewhere for a long period, and it is why it remains in place in organisations whose reporting depends on it.

Distribution decides performance

Because data is divided, how it is divided matters enormously.

Each table has a column determining which unit a row belongs to. The value is used to assign the row.

Two things follow, and they are the substance of designing tables on this platform.

Even spread keeps everything busy. A column with well distributed values puts roughly equal amounts of data on each unit. A column with few distinct values, or one where most rows share a value, concentrates data on a small number of units. Those units then do most of the work while the others wait, and the system performs as though it were much smaller.

Matching distribution avoids movement. When two tables are joined on the column they are both distributed by, matching rows are already on the same unit. The join happens locally. When they are distributed differently, data has to move between units before the join can proceed, and that movement is frequently the dominant cost of a query.

Neither of these is adjustable afterwards without redistributing the table. This is a design decision made when tables are created, and it is the one that most determines whether the warehouse performs.

Governing who gets what

A warehouse serving a large organisation has competing demands. A daily report has to complete before people arrive. An analyst runs an exploratory query over ten years of history. A scheduled process loads overnight data.

Left ungoverned, one heavy query consumes resources that everything else needs.

Workload management applies rules about how resources are allocated between classes of work. Priorities, limits, and rules about what may run concurrently.

In an environment where reports have committed delivery times, this is not a refinement. It is what allows exploratory work and scheduled work to coexist on one system.

Why it comes up in modernisation

Teradata appears constantly in discussions about modernising analytics, and the reason is worth stating plainly.

It has been in place for a long time in large organisations. Over those years, an enormous amount has accumulated around it: stored procedures, dialect specific SQL, scheduled processes, reports, and business logic embedded in transformations nobody has revisited.

The data itself is not the obstacle. Moving data between systems is a solved problem.

What is difficult is everything built on top. A report that has run for fifteen years encodes rules that exist nowhere else. Procedures written by people who have left implement logic that is documented only in the code.

Migration programmes routinely underestimate this. The technical transfer is estimated; the archaeology of establishing what still matters is not.

The practical consequence is that these programmes are as much about understanding what exists as about moving it, and treating them as data migration projects is the usual reason they overrun.

Who uses it

Teradata is used by data warehouse teams, analysts and reporting functions in large enterprises, concentrated in banking, telecommunications, retail and insurance, where it has often served as the central analytical platform for a long period.

Points to consider

Teradata is a commercial platform and the official documentation is the reference for editions, deployment options and capabilities, including its cloud offerings.

Skills are more specialised than for widely used cloud warehouses, which is a consideration for organisations planning over a long horizon.

Distribution design remains the decision that most affects performance, and existing tables designed years ago may reflect assumptions about the data that are no longer true.

Where it holds critical reporting, continuity has value that is easy to discount. Moving a dependency that works, in order to gain properties the organisation may not need, is a decision that should follow from a requirement rather than from the age of the platform.

Getting started

The official documentation covers the architecture, SQL, table design and workload management. For anyone working on an existing installation, the material on distribution and joins is the most immediately useful, since it explains the performance of queries already running.