PAM tools were built to gate the door. Databases need a tool that gates the action.
This isn't a knock on PAM as a category. StrongDM, Teleport, CyberArk, and HashiCorp Boundary are mature products that solve real problems well. The argument here is narrower: the session-based model that makes PAM work for SSH is the wrong shape for database access. If your PAM tool is doing 80% server access and 20% databases, the database 20% is the worst-fit part of your stack. Here's why.
PAM was designed for a world where the unit of work is a session. An ops engineer connects to a server, does a series of related things, and disconnects. The model:
This fits server administration well. Installing a package, restarting a service, tailing logs, checking a config file are loosely related activities that benefit from being grouped. The individual commands are usually low-risk in isolation. The thing you care about is the overall session intent, and a recording is a reasonable way to capture that.
The model is also reactive by design. It records what happened so you can investigate later. For SSH workflows, that tradeoff makes sense because most commands aren't independently catastrophic and the value comes from understanding the whole sequence.
Database access doesn't look like server administration. The unit of work is a query, not a session. Each SELECT, UPDATE, INSERT, or DELETE is independently meaningful and independently risky. A single line of SQL can drop a table, leak a million customer records, or rewrite the revenue ledger. The session intent matters significantly less than what each query does.
Three scenarios illustrate where the PAM model breaks down against real database access patterns.
An on-call engineer is debugging a production outage. Over 15 minutes they run 20 queries, each slightly different from the last. Most are SELECTs against tables they touch every day. Two are manual UPDATEs to fix corrupted state.
Under PAM, you have two options:
Neither option is good. The session is the wrong granularity.
Six months later, an auditor asks: "Who ran the UPDATE that changed the Q3 revenue numbers?"
Your PAM tool has a session recording. It's a 47-minute video of an engineer's terminal. To answer the question, you scrub through the recording, find the moment the UPDATE was typed, transcribe it, and correlate the timestamp with the user and the ticket. Multiply that work by every engineer with prod access, every session, every audit cycle.
A session recording is evidence that something was done. It's a poor index for finding which thing was done when.
An authorized user runs SELECT * FROM customers and exports the results. PAM logs the session. The data is gone before anything in the stack had a chance to inspect the query, because PAM doesn't see queries. It sees sessions.
This one isn't really a PAM failure on its own terms. PAM was never designed to inspect individual statements. But it's worth flagging because in practice many teams treat PAM as their database access control and then are surprised when it can't intervene at the query level.
The common thread: PAM is reactive. It records what happened so you can investigate later. For SSH, that's a sensible tradeoff. For databases, where a single statement can do irreversible damage, prevention matters more than forensics.
What if instead of approving sessions, you approved queries?
The flow looks like this:
Now run the scenarios again.
Scenario A. The 18 safe SELECTs flow through without friction. The 2 dangerous UPDATEs route to a senior engineer in Slack. They approve in 30 seconds and the queries execute. The incident gets resolved without creating a security incident.
Scenario B. The auditor asks who ran the revenue UPDATE. You search the audit log for UPDATE against the revenue table and get the exact query, the user, the approver, and the timestamp. No video scrubbing.
Scenario C. The SELECT * FROM customers hits a column-level data protection rule: any query that returns the email column gets the email column hashed before execution. The query is rewritten before it touches the database. The exported file contains hashed values. Raw PII never leaves the database. This is a separate control from per-query approval, and it's worth being precise about: per-query approval blocks the dangerous write, data protection rewrites the dangerous read. You want both.
This is the first objection any engineering leader raises, and it's the right one. The fix is structural, built into the policy model itself.
If every query routes to an approver, the system fails. Engineers get blocked, approvers stop reading the SQL carefully, and the whole thing collapses into rubber-stamping. The point of policy is to make sure routine queries never hit a human in the first place. A SELECT against a non-sensitive table by a developer in the right role flows through. A schema-altering DDL against prod doesn't. The ratio you want is something like 95% of queries flowing through silently and 5% routing for review.
The approval bottleneck is also a real on-call concern. At 3am, the senior engineer who'd normally approve the UPDATE might be asleep. The answers here are policy-level: define a break-glass role with broader auto-approval but heavier audit attention, support any-of-N approver pools so multiple people can unblock, route through Slack and email so notifications actually reach someone. Nothing exotic here, as it's the same or similar pattern you'd use for production deploys.
Done well, per-query approval should feel like CI: invisible when things are normal, decisive when something looks wrong.
PAM is the right answer for what PAM was built for. SSH, RDP, Kubernetes exec, cloud console access, jump hosts, infrastructure that follows a session model. If you have an enterprise stack that needs unified governance across those resources, keep PAM. Don't rip it out for SSH.
The narrower claim is that databases don't fit. Of all the resource types PAM tries to govern, databases are where the session model fits worst, where audit gaps run deepest, and where data exposure risk runs highest. A database-specific tool in front of databases gets you:
Some PAM vendors have started adding query-level controls. The reality is uneven. These features are typically gated behind enterprise tiers, limited to specific databases (Postgres-first), and operate at the level of statement type rather than full query text against table and column policy. You pay enterprise pricing for a partial fit.
QueryDesk is purpose-built for this. The policy engine, atomic per-query approvals, and pre-execution query rewriting were designed from the start to gate the action, not the door. It supports PostgreSQL, MSSQL, Oracle, MySQL, MariaDB, and others, with new databases added regularly. The features page walks through how the pieces fit together.
PAM is the right tool for sessions, SSH, and the rest of the infrastructure it was built for. Keep it there. But for database access specifically, the session model can't give you a defensible audit trail, can't give developers, end-users, or approvers a workflow that doesn't get in their way, and can't actually prevent the harm. That's what QueryDesk is built around, and the 14-day trial doesn't require a credit card.