# Bytebase vs. PAM: Why Database Teams Need More Than Privileged Access Management

> PAM tools gate the database connection. Databases also need SQL review, a schema change workflow, and per-statement approval. Here is where PAM stops and why most teams run it alongside Bytebase.

Adela | 2026-04-27 | Source: https://www.bytebase.com/blog/bytebase-vs-pam/

---

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](/blog/bytebase-vs-strongdm/), Teleport, and HashiCorp Boundary. The model is sound: vault the credentials, broker the connection, record the session, hand out [just-in-time access](/blog/just-in-time-database-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](#pam-vendor-landscape) for tool-specific notes.

|  | PAM (typical) | Bytebase |
| --- | --- | --- |
| [Primary category](#what-pam-does-well) | Privileged access management for infrastructure | Database DevSecOps |
| [Infrastructure scope](#what-pam-does-well) | Servers, Kubernetes, cloud consoles, web apps, databases | Databases (30+ engines: PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, etc.) |
| [Credential vaulting](#what-pam-does-well) | ✅ Infrastructure-wide (DBs, SSH, cloud, web) | ✅ For database credentials |
| [JIT database access](#where-pam-falls-short-for-databases) | ✅ Time-boxed connection access | ✅ Time-boxed access + per-query approval |
| [SQL review on the actual SQL](#where-pam-falls-short-for-databases) | ❌ | ✅ 200+ rules, checked before each statement runs |
| [Schema change workflow](#where-pam-falls-short-for-databases) | ❌ | ✅ Ticket-tracked rollout (dev → staging → prod) with rollback |
| [Per-query approval](#where-pam-falls-short-for-databases) | ❌ Approve the connection, not the query | ✅ Approve specific queries (e.g., DELETE on a large table) |
| [Audit log of executed SQL](#where-pam-falls-short-for-databases) | ⚠️ Session video replay | ✅ Searchable per-statement log (user, time, rows affected) |
| [Data masking](#where-pam-falls-short-for-databases) | ❌ | ✅ Per-column rules applied at query time (e.g., redact email) |
| [Web SQL editor with autocomplete](#where-pam-falls-short-for-databases) | ⚠️ 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](https://docs.bytebase.com/sql-review/review-rules/) before it runs: require a `WHERE` clause on large-table updates, block `SELECT`s 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](https://docs.bytebase.com/change-database/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](/blog/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)

```mermaid
flowchart TB
    Dev(["Developer"])
    Dev --> SSH["SSH to server"]
    Dev --> Kube["kubectl exec"]
    Dev --> DBQ["Database query"]

    SSH --> PAM1["PAM gate"]
    Kube --> PAM2["PAM gate"]
    DBQ --> BB["Bytebase gate"]

    PAM1 --> Server["Linux server"]
    PAM2 --> Pod["K8s pod"]
    BB --> Workflow["SQL review<br/>Approval policy<br/>Execute on DB<br/>Searchable audit log"]

    style BB fill:#e0f2fe,stroke:#0369a1
    style Workflow fill:#e0f2fe,stroke:#0369a1
```

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](/blog/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](/blog/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](/blog/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](/blog/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.