Column-level encryption and masking protect sensitive data in a data warehouse without preventing authorised users from working effectively. Masking shows a transformed, non-sensitive version of data to unauthorised users — a phone number appears as `+91-XXXXX-99999` instead of the actual digits. Encryption stores data in an encrypted form that only authorised users with the decryption key can read. Both approaches are applied transparently at the database layer — analysts see either the real value or the masked version depending on their role, without any application-level code change.
Snowflake's Dynamic Data Masking applies masking policies at the column level — a masking policy is a SQL expression that transforms the column value for users who do not have the unmasking role. Masking policies are decoupled from the table schema and can be applied and removed without modifying the table definition. Multiple masking policies can be applied to different columns, with each policy specifying which role sees the real value. DDM policies are versioned and auditable — every change is recorded in the account usage history.
Analogy🏏Cricket
🏏 Think of it like cricket: OLTP is the IPL's live ticketing counter — it handles thousands of simultaneous seat reservations, each requiring a precise single-seat record update with immediate confirmation. Speed per transaction and data consistency under concurrent updates are everything. OLAP is the IPL's season statistics department — it runs complex analytical queries across every ball bowled in every match of every season to produce the published rankings, economy rates, and historical comparisons. No one books a seat through the statistics department, and no broadcaster calls the ticketing counter for Bumrah's career economy rate. The two workloads demand completely different systems. Just as the ticketing counter is built for speed and correctness on one seat at a time and would buckle if asked to tally a decade of attendance mid-sale, an OLTP row-store excels at single-record writes but chokes on full-table aggregation; and just as the statistics department pores over millions of past deliveries but would be hopeless at booking a live seat under contention, the OLAP columnar engine sweeps billions of rows yet is the wrong tool for a fast single-row update. The physical design of each — row-oriented for the counter, columnar for the stats desk — is what makes it superb at its own job and unfit for the other's.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.