Guides
Apr 2, 2026
Dynamic Data Masking
Mask sensitive columns at query time, across every engine
What happens without masking on the query path
Anyone who can query sees everything
Access control decides who can connect; it says nothing about what they see once they're in. A support engineer running a legitimate query gets full SSNs, card numbers, and emails in the result grid.
Engine-native masking stops at the engine
Each database ships its own masking primitive — different syntax, different gaps, different bypasses (SYSDBA, EXEMPT REDACTION, Fine-Grained Readers). Six engines means six policies to write and keep in sync.
Static copies drift from the source
Masking by writing a scrubbed copy means a second source of truth to refresh, re-scrub, and reconcile — and it's useless for masking live production reads.
How Bytebase masks every query
Transformed at read, unchanged at rest
Bytebase rewrites sensitive values in the result set as the query runs — the stored data never changes, and there's no masked copy to maintain.
Query-time transform
Masking happens as the SELECT is answered; storage is untouched, so there's no second source of truth to keep in sync.
Role-based result
What each person sees is a policy decision, not a column property — the same column returns cleartext, last-four, or a hash depending on who asks.
One policy, every engine
Write the rule once and apply it across PostgreSQL, MySQL, SQL Server, Oracle, BigQuery, and Snowflake — instead of six engine-native dialects.
Policy that maps to your data, not your schema
Rules bind to classification, environment, project, table, or column and resolve against the requester's role — so the right people see the right values without per-query exceptions.
Bind to classification
Tag columns by sensitivity once; masking follows the classification, so new tables inherit policy instead of needing a fresh rule.
Conditions on context
CEL conditions on environment, project, and role decide what resolves — cleartext to a fraud investigator, last-four to support, a hash to an analyst.
Granular mask types
Full redaction, partial (last-four), hashing, or null — pick the transform that fits each column and audience.
Unmasking is a request, not a silent reveal
Seeing raw values goes through approval and lands in the audit log, so sensitive reads are governed and accountable — not a flag someone quietly flips.
Approval to unmask
A request to see raw values routes to an approver and is granted for a bounded scope, never an open standing exemption.
Every read audited
Who queried what, masked or unmasked, is recorded — the evidence auditors ask for, without reconstructing it from engine logs.
Masking on the human path
Masking applies to reads that go through Bytebase — the SQL Editor, exports, and query results your team touches — where raw PII would otherwise reach a person.
One masking policy, controls for every team
Integrations
Designed to integrate across modern enterprise environments
Bytebase connects to databases, developer tooling, and collaboration platforms to fit naturally into complex, multi-tool enterprise ecosystems.
Resources
