Most teams reach for Privileged Access Management (PAM) to solve one problem: who can SSH into which server. The tools that do this well are CyberArk, BeyondTrust, StrongDM, Teleport, HashiCorp Boundary, Delinea, WALLIX, and Britive. The model is sound: vault the credentials, broker the connection, record the session, hand out just-in-time access. When the target is a database, however, another layer of control appears: not just who can connect, but what SQL can run and how database changes reach production. What usually happens next is not a swap. Teams keep PAM and add a database-native layer next to it.
The short version: PAM answers who can reach the database, and Bytebase answers what can happen to it. This post walks through where PAM is strong, where the database layer needs its own controls, and how the two fit together.
This post is maintained by Bytebase, an open-source database governance platform. Vendor ownership and product details were checked in September 2026, and we update the post as they change.
Bytebase vs. PAM at a glance
The "PAM" column describes the typical posture across the eight tools in the vendor landscape below, where the tool-specific notes live.
| PAM (typical) | Bytebase | |
|---|---|---|
| Primary category | Privileged access management for infrastructure | Database governance |
| Infrastructure scope | Servers, Kubernetes, cloud consoles, web apps, databases | Databases (30+ engines: PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, etc.) |
| Credential vaulting | ✅ Infrastructure-wide (DBs, SSH, cloud, web) | ✅ For database credentials |
| JIT database access | ✅ Time-boxed connection access | ✅ Time-boxed access + per-query approval |
| SQL review on the actual SQL | ❌ | ✅ 200+ rules, checked before each statement runs |
| Schema change workflow | ❌ | ✅ Ticket-tracked rollout (dev → staging → prod) with revision history |
| Per-query approval | ❌ Approve the connection, not the query | ✅ Approve specific queries (e.g., DELETE on a large table) |
| Audit log of executed SQL | ⚠️ Varies: session replay, plus per-query events in some products | ✅ Searchable per-statement log, tied to the approved change |
| Data masking | ❌ | ✅ Per-column rules applied at query time (e.g., redact email) |
| Web SQL editor with autocomplete | ⚠️ Some (StrongDM, Teleport) | ✅ Built-in, with schema browser and query history |
What PAM does well
PAM grew out of Unix administration, and the mental model has stayed the same: credentials are dangerous, so put them behind a broker. Every major vendor implements the same core set of capabilities.
- Credential vaulting: passwords, SSH keys, and cloud tokens never live on developer laptops.
- JIT access broker: request, approve, short-lived token, auto-revoke.
- Session recording: keystrokes for SSH, network capture for DB protocols, screen capture for web consoles.
- Identity integration: SSO, group-based policy, MFA enforcement.
- Access audit: who connected, when, and with which credential.
For SSH into a Linux server, kubectl exec into a pod, or RDP into a Windows admin host, this is the right model. The high-value control is "did anyone unauthorized connect?", and PAM answers that question well.
Where the PAM model needs a database-native layer
The connection-level model that works for SSH starts to slip on databases, because the question changes shape. It is no longer only who connected, but what SQL runs, whether anyone approved it, and how the change reaches production. Five gaps tend to show up.
1. No SQL review on the actual SQL being executed
PAM gates the connection. Once you are in, you can run anything the database role permits, including DROP TABLE users; or UPDATE accounts SET balance = 0 WHERE customer_id = 12345;. PAM will record that you did it. What PAM typically does not do is evaluate the SQL itself against database-specific policy before execution.
Bytebase inspects SQL before execution against 200+ SQL review rules, for example requiring a WHERE clause on DML or enforcing schema conventions. Sensitive-column reads and production timing are governed separately, by access-control, masking, approval, and rollout policies rather than by the review rules themselves.
2. Schema change workflow sits outside the PAM model
Database changes follow a specific lifecycle: write the migration, review the SQL, validate it across environments, roll it out to production, and prepare a recovery path where appropriate. This lifecycle generally sits outside the PAM model. Migrations either get pasted into a brokered session, where they are reviewed nowhere, or they go through a separate CI/CD pipeline that bypasses PAM entirely, which leaves no joined audit trail.
Bytebase tracks schema changes as issues, the way Jira tracks tickets: target databases, the SQL, the rollout sequence, and the approval chain. This is documented in Change Workflow.
3. Approval is connection-level, not statement-level
A common PAM policy reads like this: "Engineer Alice has JIT read access to prod_db for 4 hours, approved by Bob." Inside that window, Alice can run SELECT * FROM customers WHERE 1=1, because the approval covers the connection, not the statements. The audit log shows "Alice connected with read access", which is exactly what was permitted.
Bytebase moves approval down to the statement layer: a SELECT against a sensitive table can require its own per-query approver, and a DELETE on a large table can be blocked or escalated.
4. Query visibility is not the same as change governance
Some PAM products do surface individual queries. Teleport emits a structured event per database query, carrying the statement text, the database, the Teleport user, and a timestamp, and a Postgres session can be replayed. For a forensic investigation that is genuinely useful.
Seeing the statement is not the same as governing it. Observing a query as or after it runs leaves it unattached: to a change request someone reviewed, to an approver, to a rollout sequence, to a rollback. The same ALTER TABLE produces two different records:
| Record of the same statement | |
|---|---|
| PAM | Alice executed ALTER TABLE orders ... at 14:34 |
| Bytebase | Alice proposed it, SQL review passed, Bob approved, it rolled out to staging and then production, with the resulting revision and rollout history recorded |
Bytebase logs each executed statement as a searchable row (user, timestamp, database, statement text, row count, duration), and the change that carried it stays tracked as an issue with its review and approval chain. That structured context is far easier to search, correlate, and present as audit evidence than a standalone session recording. See Database Audit Logging for the compliance-driven design.
5. No model of database change state
This is the gap that is hardest to close from the access side. PAM knows that Alice reached production. It may even know the SQL Alice executed. It does not model that SQL as version 42 of the production schema.
So the questions a team actually asks during an incident go unanswered: which change produced the column that is there now, whether staging and production are on the same revision, which one introduced the index someone is asking about, and what rolling it back would involve. Those need a system that treats a change as an object with a version and a history, not as a session with a recording.
Bytebase treats it that way by default, because the change is the unit of work rather than the connection: every applied change keeps the issue that authorized it, the statements it ran, its rollout history, and the resulting database revision. Where a rollback path exists, it stays attached to that change. Schema synchronization is how two databases get compared when the question is whether they still match.
The hybrid pattern (recommended for most teams)
PAM owns infrastructure-wide access. Bytebase owns the database step. Both authenticate against the same identity provider, so policy decisions reference the same user. The audit trail in PAM shows "Alice connected to db.prod-1 at 14:32"; the audit trail in Bytebase shows "Alice ran UPDATE accounts SET status='frozen' WHERE id IN (...) at 14:34, approved by Bob, affected 47 rows." Put together, they answer the whole question.
This hybrid setup is a strong fit when PAM is already deployed, database access volume is meaningful, compliance scope (SOC 2, ISO 27001, HIPAA, PCI) covers the database, or schema changes happen more than once a month.
When one is enough
PAM alone may be enough when direct database access is rare (a few queries a week, mostly by DBAs), schema changes are infrequent, database privileges are already tightly constrained, and query-level governance is not a compliance requirement. Headcount is a poor proxy for this: a ten-person fintech can sit well outside it while a larger team with read-only analytics sits comfortably inside.
Bytebase alone is enough if the stack is database-only, with no servers, no Kubernetes admin, and no cloud consoles to gate. This is common at companies on managed databases such as Supabase, Neon, RDS-only, PlanetScale, or Aurora-only, where there is no underlying server to SSH into. As the infrastructure footprint grows, PAM tends to get added back for the non-database surface.
PAM vendor landscape
Each major vendor's database story in one line:
| PAM Tool | Strength | Database gap |
|---|---|---|
| CyberArk | Most mature enterprise credential vault; broadest compliance certifications. Now part of Palo Alto Networks, which closed the acquisition in February 2026 | No database-native SQL review or schema change workflow |
| BeyondTrust | DevOps Secrets Safe for CI/CD secret injection | No database-native SQL review or schema change workflow |
| StrongDM | Modern UX, JIT-first design, strong web SQL pad | Detailed comparison: Bytebase vs. StrongDM |
| Teleport | Open-source friendly, k8s and SSH-native, with strong database access and per-query audit | No database-native SQL review or schema change workflow |
| HashiCorp Boundary | Open-source PAM, Terraform-native. Part of IBM since the HashiCorp acquisition closed on 27 February 2025 | Focuses on identity-aware session brokering rather than SQL or database change governance |
| Delinea | Enterprise vaulting with less operational weight than the heaviest platforms; developer and database access from one vendor | No database-native SQL review or schema change workflow |
| WALLIX | European vendor with unusual reach into OT alongside IT; Bastion for session brokering, PAM4ALL to extend zero-trust access to all users | No database-native SQL review or schema change workflow |
| Britive | Cloud-native, built on zero standing privileges: permissions are created on request and revoked after the task, with no vaulted database credential to rotate | Ephemeral permissions still grant a connection, not a reviewed statement |
Despite meaningful architectural differences between them, and Britive's zero-standing-privilege model is a good example, the common boundary holds: none of these products centers its database model on SQL review, migration workflow, and schema lifecycle governance. That is not a knock against them. They are solving the access problem, which is a different problem.
Britive is the useful edge case here, because its architecture sits furthest from the vault-and-broker design the others share. With zero standing privileges there is no long-lived database credential to steal, which closes a genuine risk that vaulting only manages. And that still does not make the SQL itself a governed change object. Removing standing credentials and governing the statement lifecycle are two different problems, and a team can need both on the same database.
Which should you choose?
The "which one" framing usually has the wrong shape, because for most teams it is not an either/or.
You probably need PAM if you have any infrastructure surface at all: servers, Kubernetes, cloud admin consoles. You probably need Bytebase if databases are a meaningful part of the access surface and someone will eventually ask "what SQL ran?" in an audit. And if both of those are true, you probably want both. The cost of running the two together is lower than the cost of either gap.
The replacement framing only holds at the edges. A database-only startup runs Bytebase without PAM; a database-rare team runs PAM without Bytebase. Most teams in the middle end up needing both layers.
It helps to name the two categories precisely, because they overlap in the middle and diverge above and below it. Both vault database credentials and gate who can connect. PAM also vaults SSH keys, cloud tokens, and web-app credentials across the whole infrastructure. Database governance instead adds SQL review, a change workflow, database access governance, and statement-level audit on top of that same connection.
They solve different layers of the same database control problem: PAM governs access to the database, while Bytebase governs the SQL and change lifecycle inside it. For many production environments, that makes the two complementary rather than interchangeable.