Bytebase vs. Teleport: a side-by-side comparison for database access control and JIT

"Bytebase vs Teleport" comes up when a platform team already runs Teleport for SSH and Kubernetes and asks whether its database access module is enough. Sometimes it is. Teleport's database layer goes deeper than most access brokers: per-query audit events, table-level permissions on PostgreSQL, automatic database user provisioning. Bytebase is a database governance platform covering schema changes, SQL review, access control, and data masking. The two meet at just-in-time (JIT) database access; the question is what has to be governed once the session is open. Written against Teleport 18.11 and Bytebase 3.23.

Bytebase vs Teleport at a glance#

Different problems, overlapping capabilities#

Teleport is an infrastructure identity platform. It replaces long-lived credentials with short-lived certificates issued from your SSO identity, for every resource a person or a machine might touch: servers, Kubernetes clusters, web apps, desktops, databases, and since 18.1 the MCP servers that AI agents call. Every connection is recorded under the identity that opened it.

Bytebase is a database governance platform: schema migrations with SQL review, approval flows, dynamic data masking, batch changes across environments, and JIT query access. It does not know about SSH or Kubernetes.

The overlap is JIT access with an audit trail. Where the two pull apart is what happens inside the session. Teleport's unit of control is the connection: who may open it, as which database account, for how long, and what was typed into it. Bytebase's unit of control is the statement: what SQL is about to run, whether it passes review, who approved it, and what the result set may show.

Organizations that run both split the work that way: Teleport issues the identity and records the session, Bytebase runs the database workflow. For the patterns, see just-in-time database access and database access control best practices; note.com runs the Bytebase side in production.

Schema change and SQL review#

Only Bytebase has this. Teleport authenticates the connection and logs what ran. It does not inspect the SQL before it executes, and it has no concept of a schema change as a unit of work.

Bytebase gates DDL and DML (schema and data changes) through an issue that runs SQL Review (200+ engine-specific rules on every tier) and an approval flow before anything deploys. The same issue carries the rollout across environments and the record for rollback and audit.

A Teleport-only shop still needs a change tool. Liquibase and Flyway run in CI, and so does Bytebase, which is API-driven: in its GitOps workflow, a CI job such as a GitHub Action calls that API to check and roll out the change, so it slots into a pipeline the same way the CLI tools do. Without one, the answer to "who approved this ALTER TABLE" is spread over a pull request, a session recording, and a ticket.

Access and approval#

• Teleport maps your SSO identity to roles that list the database accounts (db_users), logical databases (db_names), and database roles a user may use. Two details are easy to miss: db_names is only enforced for PostgreSQL, MongoDB, and Cloud Spanner, not MySQL; and table-level permissions (db_permissions) are PostgreSQL-only, granted for the life of the connection. JIT comes from Access Requests: a user asks for a role or a resource, a configurable number of reviewers approve, the access expires. Plugins notify Slack, Jira, PagerDuty, Opsgenie, Mattermost, Discord, Microsoft Teams, ServiceNow, Datadog, and email. Reviewing in the Web UI and dual authorization are Enterprise; Community users can request roles from the CLI only.
• Bytebase uses workspace and project RBAC with per-environment policy, so a query that is fine in staging can require approval in production. JIT has two shapes: a time-boxed role request for ongoing work, and an access grant for one approved read-only statement, optionally with unmask and export, from one hour to seven days. The approver sees the statement, the review result, and the environment policy in one issue.

The practical difference is where the approval attaches. Teleport approves a session, then records what happens in it. Bytebase approves a statement, then runs it. For one-off production reads the Bytebase grant is narrower; for an afternoon of work with your usual tools the Teleport request fits better.

Database users: Teleport creates them, Bytebase does not. With automatic user provisioning on (PostgreSQL, MySQL, MariaDB, Redshift, self-hosted MongoDB), Teleport uses an admin account to create a database user named after the Teleport user, and at session end locks it (keep) or drops it (best_effort_drop). The database's own session list shows the real person. Bytebase works the other way: the database sees the account configured on the instance, and Bytebase's audit log records who ran what. To automate CREATE ROLE and GRANT you run them as a database change with review and approval, optionally to many databases at once. Teleport's model wins when native database audit must name the person. Bytebase's wins when you do not want an access tool holding a CREATEROLE account on every production database.

Data masking#

• Teleport: no masking. Access control decides which database, account, and (on PostgreSQL) which tables a user reaches; the rows the database returns are the rows the client sees.
• Bytebase: dynamic data masking with semantic types (email, phone, card number). Admins tag columns or set global rules; results in SQL Editor and exports are masked, and exemptions go through approval into the same audit trail.

For PCI, HIPAA, or GDPR workloads where an engineer needs the table but not the values, this is Bytebase-only.

SQL editor#

• Teleport: no built-in editor. Teleport Connect, the desktop app, opens a local tunnel and shows a "Connect with GUI" section; you bring psql, mysql, DBeaver, or DataGrip.
• Bytebase: a browser SQL editor with a schema browser, saved sheets, query history, and masking applied inline. Engineers who only need query access never install a client.

Teleport's approach is fine for a team standardized on a GUI client. Bytebase's editor matters when you want one query path that enforces masking and export policy.

Audit log#

• Teleport emits db.session.start, db.session.query, and db.session.end events; the query event carries the statement text, the database account, and the Teleport user. Sessions are recorded too: PostgreSQL recordings play back interactively, every protocol exports as JSON. The same stream holds SSH and Kubernetes sessions: one timeline for all infrastructure.
• Bytebase logs every query, export, schema change, approval, access grant, masking exemption, and admin action, readable through the API or streamed as JSON to stdout for a SIEM such as Splunk, Datadog, or Elastic. The audit log is on Pro (7-day retention) and Enterprise (unlimited); see audit log for SOC 2 compliance for the control mapping.

For "every privileged session across servers, clusters, and databases," Teleport's log answers in one place. For "who approved this change, what the review said, and who later read the masked column unmasked," Bytebase's log has the fields.

AI agents and MCP#

• Teleport does not ship an MCP server. It protects MCP servers you already run, the way it protects a database: it decides which users and agents may call which tools, and logs every call.
• Bytebase ships its own MCP server. The agent signs in as a Bytebase user, a workspace policy caps every session at Read-only (the default) or Read-write, results are masked, and calls are audited.

Supported databases#

Teleport covers PostgreSQL, MySQL, MariaDB, SQL Server, Oracle (Enterprise only), MongoDB, Redis, Cassandra, ClickHouse, CockroachDB, Elasticsearch, Snowflake, and the managed variants on AWS, Azure, and Google Cloud. Bytebase covers 25 engines, the same relational core plus TiDB, OceanBase, Spanner, DynamoDB, Cosmos DB, BigQuery, Redshift, and Databricks (feature matrix). Depth matters more than the count: on Teleport, PostgreSQL gets everything and MySQL gets less; on Bytebase, the change workflow runs everywhere while SQL lint covers eight engines and data rollback four.

Pricing and licensing#

One honest note: the free tiers are not equivalent. Teleport Community is a license restriction (company size) that lacks OIDC/SAML and reviewed access requests; Bytebase Community is a capacity restriction that lacks JIT, masking, and the audit log. A team that needs reviewed JIT is paying either way.

Which should you choose?#

• Pick Teleport if the primary need is zero-trust access across servers, Kubernetes, apps, and databases under one identity. Per-query audit and PostgreSQL object permissions make it a credible database access tool on its own; the depth drops off outside PostgreSQL.
• Pick Bytebase if the primary need is governing what runs in the database: schema changes with review and approval, masked query access, one-statement grants, and an audit trail that ties the approval to the SQL. Open source without a company-size limit.
• Run both if Teleport is already in front of your infrastructure and you keep hitting its edges on databases: no SQL review, no masking, no change workflow. Teleport keeps the identity and the session; Bytebase takes the statement.

My own read: if Teleport is deployed, keep it and add Bytebase for the change and masking side. If neither is, and the problem is "developers and agents touching production data," start with Bytebase; you will know later whether you need the PAM layer. See also Bytebase vs. PAM and the StrongDM comparison.