Bytebase database newsletter with SQL development, PostgreSQL, MySQL, schema migration, governance and database DevOps insights.
By Bytebase
Governance only counts if you can prove it happened — and “can’t tell the auditor who changed or accessed what, and when” is its own problem, usually patched with a spreadsheet somebody maintains by hand until they stop.
Access control decides who can query a table. Masking decides what comes back — the analyst who needs the orders table has no business reading the email addresses in it.
Who can query what is usually decided once, at onboarding — access is handed out for a single investigation and quietly stays for years.
Most of governance is about stopping bad changes. Some get through anyway — reviewed, approved, valid, and still wrong. What matters at that point is how fast you can put things back.
Every team has someone who knows that this particular ALTER will lock the table for twenty minutes. SQL review is that knowledge written down once — so it runs at 2am too, on the change no one is watching. The rules are what a careful DBA would say out loud:
Bytebase is one control plane between your users and your databases. However you connect, the same permissions, masking, and audit trail apply.
In Read-write mode, an agent connected through MCP can now take an access request from start to finish. The mode does not grant permissions: an agent can do only what the signed-in user can do in Bytebase, and the project's approval rules still apply.