Database access without handing out the password
The production database password is usually the worst-kept secret a company owns: in a password manager, in a CI variable, in three laptops and one old runbook. Brokering it means nobody receives it in the first place.
Why the shared login survives everything
Nobody defends it. It persists because every alternative has been more expensive than living
with it. Per-person database roles mean managing roles in every environment and reconciling
them with leavers. A bastion with a shared psql history solves nothing. So the
password stays in the password manager, and the honest answer to who can read the production
database is everyone who has ever worked here.
The version of this that shows up in an audit is narrower and harder: not who has access, but what they ran, on a date somebody else picked.
What brokering changes
The login is injected, and the client does not change
An engineer points their usual client at a local port. The controller opens the real connection and supplies the stored login on their behalf. They never see it, cannot copy it, and cannot keep it after their grant expires. Adding a database is entering a host, an engine and a credential once.
Read-only is a property of the connection (Pro and above)
Writes and DDL are rejected at the protocol layer, before the statement reaches the server. That is a stronger claim than a read-only role, because it does not depend on the role being correct in every environment, and it can be applied to a session that is already open: an administrator can downgrade somebody from read-write to read-only without a reconnect, which is the thing you actually want in the middle of an incident.
This one is not in the free edition. Community brokers the connection and records the queries, but every session is read-write, and asking for read-only gets you read-write rather than an error.
Every statement is written down
Successful queries are recorded, in every edition, on by default. Blocked ones are recorded too, which is usually the more interesting entry. The record lives outside the database, so it does not depend on the database's own logging being switched on and retained by the same people whose access is being reviewed.
What this is not
It is not a secrets manager and it does not rotate anything for you. What it does is remove the reason rotation is urgent: a credential nobody has received does not leak when somebody leaves. When you do rotate, you change one stored value instead of hunting for copies.
The rest of the estate
The same broker covers SSH, Kubernetes and Windows over RDP, with one set of grants and one audit log across all of them. If an audit is what brought you here, the direct answer is what an auditor asks for. If it is standing access you want to get rid of, that is just-in-time access.
Questions people ask before they try it
- Which databases are supported?
- PostgreSQL and MySQL today. Both are brokered the same way: the client connects to a local port and the controller injects the real login.
- Do people keep using their own client?
- Yes. psql, mysql, DataGrip, TablePlus, whatever is already on the machine. They point at a local port instead of at the database, and nothing else about their workflow changes.
- How is read-only enforced?
- In the wire protocol, before the statement reaches the server. Writes and DDL are rejected by the broker rather than relying on a database role being correct. It starts at Pro: on Community every session is read-write, and a read-only request is granted as read-write rather than refused.
- Are queries recorded?
- Yes, and in every edition including Community, on by default. Turning the recording off is the part that needs Ultimate, which is the right way round.
- Does this rotate the database password for me?
- No. It removes the reason the password needs rotating on a schedule, because no person ever receives it. Rotating it remains yours to do, and doing it means changing one stored credential rather than chasing everyone who has a copy.