Share

Switching from Teradata to Snowflake: What to Know About DML Statements and Data Deletion

Switching from Teradata to Snowflake: What to Know About DML Statements and Data Deletion
arch2

In this blog post, I will show you what you need to pay special attention to when switching from Teradata to Snowflake.


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


We will analyze the impact of running DML statements (e.g., UPDATE or DELETE) in Snowflake and contrast it with Teradata's Row Storage and Column Storage.

What happens when Teradata Rows are deleted from a table that is not Column-Partitioned?
When deleting, the rows in the data blocks are released. Teradata uses an array of pointers in each data block that points to each row's physical position within the data block.

Data blocks are merged if too few rows remain in a data block.

An UPDATE statement causes the data block to be assembled in memory.
Depending on the effect of the update on the used space within a data block, it is split into several blocks or merged.

What happens when Teradata Rows are deleted from a table that is Column-Partitioned? If all rows or an entire row partition of a table is deleted, they are physically deleted.

Otherwise, the rows to be deleted are only marked with a delete flag but continue to occupy space, which is necessary to keep the column containers synchronous.

The old Row-Based Engine comes into play during the UPDATE:
It selects the needed rows and assembles the column containers into rows. The rows to be changed will be marked with a delete flag but not deleted. The changed rows are transformed into column format and saved.

What happens when data is deleted or modified in Snowflake?Snowflake stores data in micro partitions between 5 and 500 megabytes.

Every change (UPDATE, INSERT, or DELETE) to a micro partition means that Snowflake must replace the entire micro partition.

Making changes to an existing micro partition is not possible because Amazon S3 does not support this.

Micro partitions are created when loading an empty table. If data is added, new micro partitions are created.

If a change through an UPDATE or DELETE statement is necessary, Snowflake deletes the existing micro partition and replaces it with a new one.

I assume that micro partitions are not deleted immediately but remain available for the Time Travel feature for a while.

How can the performance of both systems be assessed?I am currently missing more details about the implementation in Snowflake, but I will stay on it and update you as soon as I know more!


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