Are you comfortable implementing Snowflake and Databricks with a similar model? Why would you need SCD Type 2 when implementing? Both cannot make sense if you’re leveraging either Delta Lake or Iceberg. What is the rationale to use SCD Type 2?

SCD Type 2 is used when you need to preserve the full history of changes to a dimension record. In Snowflake, you can implement it by adding surrogate keys, effective dates, and a current flag, and using MERGE statements to insert new rows while marking old ones inactive. In Databricks with Delta Lake, you can achieve the same by using Delta’s MERGE and time‑travel features, or by leveraging Delta Lake’s built‑in support for upserts. The rationale for SCD Type 2 is to support auditability, trend analysis, and regulatory compliance. Even though Delta Lake and Iceberg provide versioning, they do not automatically maintain business‑level history for dimension tables; you still need to model the history explicitly. Therefore, implementing SCD Type 2 ensures that downstream analytics can reference the state of a dimension at any point in time, which is critical for financial reporting, fraud detection, and customer lifecycle analysis.