A slowly changing dimension of Type 1 keeps only the latest value of each attribute. When a value changes, the row is updated in place and the old value is lost. It is simpler and smaller than Type 2, and the right choice when history does not matter, such as fixing a misspelled name.
For example, a customer dimension holds a row for customer 42 with the email old@example.com. The customer changes their email, and the next load sees new@example.com. With Type 1, the pipeline updates customer 42's row in place, and from then on every report shows the new email, including reports about orders placed years ago. Nothing records that the email was ever different.
That is the right behavior for corrections and for attributes whose history nobody needs: fixing a typo in a name, filling in a missing phone number or updating a product description. It is the wrong behavior when reports should reflect the value at the time of each fact, such as the sales region a customer belonged to when they ordered. Overwriting the region moves past sales to the new region and changes last year's regional totals.
Type 1 is usually implemented as a merge on the natural key: update when the key exists and a value differs, insert when it does not. Comparing a hash of the tracked columns avoids rewriting rows that did not change. Besides Type 2, which adds a row per change, there is Type 3, which keeps the previous value in an extra column. See also deduplication.
On Databricks, a Type 1 update is a MERGE INTO on a Delta table; on Snowflake, a MERGE statement, often fed by a stream of changed rows. Either way, the dimension keeps one row per key, which keeps joins simple and the table small. See also SCD Type 2 and dimension.
Many dimensions mix both: some columns tracked with history, others overwritten. Emolysis's SCD Type 2 shape lets you mark which columns keep history and which are simply updated, so one dimension can use both approaches.