Result-side masking vs pre-execution query rewriting: where your sensitive data goes
Most data masking tools let sensitive data leave the database and hide it before display. QueryDesk rewrites the query so the protected values never leave the database.
The two look the same in a result grid. They differ in what the masking tool holds, what the audit log can prove, and how you answer a SOC 2 auditor. If you’re evaluating database access tools, ask which one a vendor built.
The two architectures
When a tool says it masks customers.email, it means one of two things.
Architecture A: mask-on-return. A user runs SELECT email FROM customers. The database returns the real email addresses to the masking tool, which replaces each value with ****@****.com before the user sees it. The raw data left the database and sat in the tool’s memory. Whether the user sees it depends on the tool masking correctly on every code path, every time.
Architecture B: rewrite-before-run. A user runs SELECT email FROM customers. Before the query reaches the database, the tool replaces the protected column with a constant, so the query that runs is SELECT ‘***’ AS email FROM customers. The database returns the constant. The real email never left the database, and no response ever held it.
A user sees *** either way. Only one of them kept the data in the database.
What this looks like in practice
This claim is easy to make, so here it is in QueryDesk.
Run SELECT email FROM users against a table whose email column is hidden, and you get back ***. That is the literal string the rewrite put in place of the column before the query reached the database, not a masked copy of the real value.
Derived values show the difference best. Run SELECT length(email) FROM users. A mask-on-return tool returns the true length of each email, because the database computed length on the real value and the tool masked only the output. QueryDesk returns 3, the length of ‘***’. The same goes for substring, left, or any other function in the select list. Each one runs against ***, so none of them can rebuild the value underneath.
Filters are where a constant would give wrong answers. WHERE email = ‘sam@acme.com’ run against *** would match no rows, and a join on a hidden column would match every pair. So QueryDesk doesn’t run them. A query that filters, joins, sorts, groups or aggregates on a hidden column is refused before it reaches the database, with a message naming the column. A member who needs the real value can request an unredacted run, which goes to review, on databases that allow it.
Why the difference matters
It shows up in four places.
Breach surface. In mask-on-return, cleartext sensitive values pass through the masking tool. A compromised tool host, a log sink that captures result sets, or a debug flag left on in production can expose data the tool was meant to hide. In rewrite-before-run, the tool never asks the database for protected values, so it has none to leak.
Audit trail. A mask-on-return log says the user ran SELECT email FROM customers, got 10,000 rows, and the tool masked them. Your auditor has to trust that the masking ran and that raw values weren’t logged or kept in memory. QueryDesk’s audit log records the SQL that ran, SELECT ‘***’ AS email FROM customers, and which columns each policy hid. The auditor can see from the log alone that the database was never asked for the email column.
In a SOC 2 Type II audit, the auditor samples query activity and asks you to show that sensitive data exposure was prevented. With mask-on-return, you point to the masking configuration and say it ran. With rewrite-before-run, you point to the SQL that hit the database, which never selected the column.
Data residency. If regulated data has to stay inside a specific database, a mask-on-return tool copies cleartext into its own memory on every query. Whether that breaks a commitment depends on where the tool runs, how your legal team reads your residency terms, and what your DPA promises. With rewrite-before-run the question doesn’t come up, because the cleartext stays in the database.
Insider risk. In mask-on-return, anyone who can read the tool’s logs or memory can see cleartext, such as a developer with log access or an SRE debugging with verbose logging on. With rewrite-before-run there is no raw copy at the tool to find. Seeing cleartext takes a policy that shows the column, or an unredacted run that a reviewer approved.
Where the market sits
Most masking features in the database access market are mask-on-return. That includes Bytebase Enterprise’s column-level masking. Bytebase does good work on schema change management, and its masking is solid for what it is. Its docs say the masking applies to query results rather than rewriting the SQL. That choice fits the rest of their product, and it decides where your sensitive data goes.
PAM tools such as StrongDM, Teleport, CyberArk PSM, and HashiCorp Boundary mostly don’t mask database data at all. They control sessions, and some redact output in session recordings. Recording redaction changes what gets stored, not what the user saw during the session.
SQL clients such as DBeaver Team Edition and CloudBeaver Enterprise generally don’t mask data either. Some integrate with secret managers to rotate credentials, which protects credentials, not data.
QueryDesk does rewrite-before-run. You set a policy per column, or write rules that match columns by name or type, and each column is shown or hidden. The rewrite applies to every query, including one a reviewer approved. It applies to every query an AI client such as Claude, ChatGPT, or Cursor runs, too, combined with the database’s AI data protection policy, and the stricter rule wins for each column. We don’t know of another tool in our category and price range that rewrites before the query runs. Enterprise data security platforms such as Satori and Immuta cover masking, but they sell to a different buyer at a different price.
When mask-on-return is fine
Mask-on-return works for many cases. If you’re hiding salaries from non-finance users in an internal analytics tool, the data already sits in your warehouse, and the threat is a marketing analyst seeing an engineer’s pay. A mask-on-return tool handles that.
The same goes for development environments on staging data, or BI dashboards over data that’s already aggregated. The risk there is casual exposure to the wrong person, and the architecture doesn’t change the outcome. Mask-on-return is simpler to set up and usually cheaper.
The architecture matters when:
- A compliance framework audits where PII or other regulated data resides, such as SOC 2 CC6.1, ISO 27001 A.8.11, GDPR Article 32, or HIPAA technical safeguards. The auditor asks what controls prevent unauthorized exposure, not whether the user saw the data, and the two questions have different answers.
- You’ve made data residency commitments to customers in a DPA or sales contract.
- You need to control insider risk at the tool, not only at the user.
- You want the audit trail to show on its own that sensitive data never left the database.
If none of these apply, mask-on-return works. If any do, you want rewrite-before-run, and you should ask vendors which one they built, because most won’t say. When a vendor says yes to “do you do data masking,” ask where in the query path the masking happens, before or after the query reaches the database.
The question to ask
Which architecture fits depends on your threat model and your auditor.
Any vendor should answer that question clearly. If they say masking applies to results, that’s mask-on-return, and you can weigh it against the cases above. If they say the SQL is rewritten before it reaches the database, that’s rewrite-before-run, and you can show your auditor the SQL that ran.
We built QueryDesk on rewrite-before-run because our customers work in compliance-heavy industries, where auditors ask what prevented exposure. Understand the trade-off, then pick the tool that fits.
To see the rewrite on your own data, start the 14-day free trial. It doesn’t need a credit card.
We checked the Bytebase capabilities in this post against Bytebase’s public documentation in June 2026. If anything is out of date, tell us and we’ll correct it.
