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, and HashiCorp Boundary. The model is sound: vault the credentials, broker the connection, record the session, hand out just-in-time access. Then the same tool gets pointed at a database, and it still gates the connection but goes quiet on the part that actually matters, which is what someone does once they are in. What usually happens next is not a swap. Teams keep PAM and add a database-native layer next to it.
This post walks through where PAM is strong, where it runs out of road for databases, and how the two pieces fit together.
Bytebase vs. PAM at a glance
The "PAM" column describes the typical posture across CyberArk, BeyondTrust, StrongDM, Teleport, and HashiCorp Boundary. See the vendor landscape for tool-specific notes.
| PAM (typical) | Bytebase | |
|---|---|---|
| Primary category | Privileged access management for infrastructure | Database DevSecOps |
| 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 rollback |
| Per-query approval | ❌ Approve the connection, not the query | ✅ Approve specific queries (e.g., DELETE on a large table) |
| Audit log of executed SQL | ⚠️ Session video replay | ✅ Searchable per-statement log (user, time, rows affected) |
| 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.
- Connection-level audit: who accessed what, and when. Not what they did once inside.
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 PAM falls short for databases
The connection-level model that works for SSH starts to slip on databases, because the question that matters changes. It is no longer "who connected?" but "what did they run?" Five gaps tend to show up in production.
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. It will not stop you, did not look at the statement, and has no way to tell whether the change is safe.
Bytebase parses every statement against 200+ rules before it runs: require a WHERE clause on large-table updates, block SELECTs on sensitive columns without masking, restrict schema changes to maintenance hours.
2. Schema change workflow is missing entirely
Database changes follow a specific lifecycle: write the migration, review the SQL, run it on dev, run it on staging, run it on production, with a rollback ready. PAM has no concept of any of this. 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, the approval chain, the rollback script. 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. Session recording is not the same as a structured audit log
A 30-minute database session in PAM produces a 30-minute video. To answer "who deleted rows from orders last Tuesday?", a compliance team has to find every session that touched orders and watch each recording. That is not what auditors mean by an audit log.
Bytebase logs each executed statement as a searchable row: user, timestamp, database, statement text, row count, duration. SOC 2 and PCI auditors accept this format directly, and the same question becomes a single SQL query against the audit table instead of hours of video review. See Database Audit Logging for the compliance-driven design.
5. No native database idioms
Power users do not want a session-recorded SSH wrapper that proxies to psql. They want psql itself: autocomplete, schema browser, query history, the \d shortcuts they already know. PAM brokers the raw protocol, but what developers see is a stripped-down terminal or a generic SQL pad. That friction is what pushes power users toward shadow tools, like a bastion host with psql that quietly bypasses PAM "for productivity."
Bytebase's web SQL Editor speaks the native protocol, with autocomplete from the live schema, per-user query history, saved queries, and result export, and there is no session-recording overlay sitting between the developer and the database.
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 is the right setup if 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 is enough if database access is rare (a few queries a week, mostly by DBAs), the schema is stable, auditors accept session recordings as evidence, and the database surface is low-risk (read-only analytics, no PII). Most companies under 20 engineers fit this profile.
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 | No database workflow layer; pricing is enterprise-only |
| BeyondTrust | DevOps Secrets Safe for CI/CD secret injection | Same connection-level model — no SQL review, no schema workflow |
| StrongDM | Modern UX, JIT-first design, strong web SQL pad | Detailed comparison: Bytebase vs. StrongDM |
| Teleport | Open-source friendly, k8s and SSH-native | Database access is a feature; SQL review and approval policy are not |
| HashiCorp Boundary | Open-source PAM, Terraform-native | Newer to the database story; less feature depth |
The pattern is the same across all five: each one does PAM well in its niche, but none of them reads the SQL or runs database-specific approval logic. That is not a knock against them. They are simply different products.
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. Everyone in the middle runs both.
FAQ
Is Bytebase a PAM tool? No. Bytebase is a database DevSecOps platform: schema change workflow, SQL review, access control, and an audit log, all for databases specifically. PAM covers infrastructure-wide access across servers, Kubernetes, and cloud consoles. The two overlap at JIT database access, but the broader categories are different.
Can PAM tools manage database access? Yes, at the connection level. PAM brokers the connection, vaults the credential, and records the session. What it does not do is read the SQL, approve individual queries, run a schema change workflow, or produce a searchable log of every query that ran.
Do I need both PAM and Bytebase? Most enterprise teams do. PAM owns infrastructure access (SSH, kubectl, cloud admin). Bytebase owns the database step (SQL review, approval policy, audit log). Both authenticate against the same identity provider, so it stays one login for the user. See Database Access Control Best Practices for the broader design.
How does Bytebase compare to StrongDM for database access? StrongDM is a PAM tool with a strong database story; Bytebase is database-native. In practice the two are deployed together more often than against each other. Full breakdown: Bytebase vs. StrongDM.
Can Bytebase replace CyberArk for database access? For database-only access, yes: Bytebase can be the sole control plane. For server, Kubernetes, and cloud admin access, no, those need PAM. CyberArk is rarely removed from an enterprise that already has it.
What's the difference between database PAM and database DevSecOps? Both vault database credentials and gate who can connect. The difference is what sits above and below that. PAM also vaults SSH keys, cloud tokens, and web-app credentials across the whole infrastructure; database DevSecOps adds SQL review, change workflow, database access governance, and statement-level audit on top of the database connection. Different layers, and most production deployments use both.
Does PAM cover SQL injection or DML risk? No. PAM logs the session that contained the SQL, but it does not analyze the SQL itself. Static and policy-based SQL review (Bytebase) works at a different layer, parsing each statement before execution and applying rules.