When it comes to protecting sensitive data, performance and simplicity matter. ALTR’s data masking policies help enforce least-privileged access by hiding sensitive values when users don’t need to see them. But in high-volume environments, even small delays from policy enforcement can add up.
That’s why we’ve introduced native masking for tag-based policies, which delivers faster performance by running masking logic directly inside your data platform.
The Problem: Great Policy, Slower Queries
ALTR’s tag-based masking policies are a flexible, scalable way to protect sensitive data. Until now, these policies were solely enforced through external function masking. When a query hit a masked column, the platform would make an API call to ALTR to determine whether to return the real or masked value.
This approach enabled powerful features like:
- Dynamic policy logic
- Real-time updates
- Near-real-time audit logs
- Tokenization and decryption
But it also meant each query made an external call, which could impact performance—and in some environments, like Databricks, this execution model wasn’t supported at all.
>>> You Might Also Like: Static vs Dynamic Data Masking: What to Use Where
The Solution: Native Masking for Tag-Based Policies
Native masking solves these challenges by running tag-based masking policies natively inside your data platform. There are no external API calls—just fast, local execution of masking logic where your data lives.
- In Databricks, native masking is automatically used for all tag-based masking policies. Since external functions aren’t supported in Databricks, this unlocks masking capabilities that weren’t previously available.
- In Snowflake, you now have a choice:
- Use default masking (i.e., external function masking) for more masking types, real-time updates and audit logging.
- Or enable native masking to improve query performance when your masking policies are relatively stable and audit trails aren’t required.
>>> You Might Also Like: Column vs. Tag-based Masking Policies in Snowflake
What’s the Difference?
Here’s a breakdown of how native masking compares to the traditional external function approach—specifically for tag-based masking policies:
Native Masking | External Function Masking | |
Executes Inside Platform | ✅ | ❌ (requires API call to ALTR) |
Performance | Faster queries | Slightly slower (external call) |
Audit Logs | Relies on native audit logs | Near-real-time audit logging |
Policy Updates | Takes time to apply, depending on policy complexity” | Real-time |
Masking Options | Basic masking types | Full feature set, including detokenization and format-preserving encryption |
Use Cases | Performance-critical, stable policies | Dynamic policies, compliance, observability |
Get Started
If you’re using tag-based policies in Snowflake or Databricks, native masking gives you a faster, more efficient way to enforce data protection without sacrificing security.
Visit our documentation to learn how to enable native masking in Snowflake or just start tagging columns in Databricks—native masking is already built in.
Have questions or wondering which method is right for your environment? Contact us—we’re happy to help.
Key Takeways
- Only tag-based masking policies are supported by native masking.
- In Databricks, native masking is the default and only option—it’s built in.
- In Snowflake, you can choose between native masking or default masking (i.e., external function masking) depending on your performance and policy needs.
