Comparison

Bytebase vs pgfence

An honest comparison: Bytebase (a mature, 200+ rule database governance platform spanning 20+ database engines) and pgfence (a focused, MIT-licensed Postgres migration safety analyzer with a lightweight control-plane add-on).

What Bytebase is best at

Bytebase is a database governance platform, self-hosted or run as Bytebase Cloud. As of v3.22.0 it ships change management (plan, review, approve, deploy), access control (RBAC, just-in-time access, dynamic data masking), and compliance (audit logging, policy-as-code, data classification) across 20+ database engines including PostgreSQL, MySQL, MongoDB, Snowflake, and ClickHouse. Its SQL Review feature ships 200+ lint rules by Bytebase's own count, spanning naming, statement, table, column, and index checks. If your org needs one platform where humans and CI both request, review, and approve every database change with a full audit trail, Bytebase is a strong fit.

Important honest framing: this is the comparison with the most direct overlap on our own roadmap. pgfence Cloud, the paid layer we are building on top of the free CLI, is a lightweight version of the same idea Bytebase already ships at platform scale: policies, approvals, and an audit trail for who approved a risky migration and when. The distinction that matters is OSS-first versus platform-first, not who has more checkboxes. The table and sections below are written with that in mind.

Feature comparison

Feature Bytebase (v3.22.0) pgfence (v0.8.0)
Category Database governance platform (change mgmt, access, compliance) Migration safety analyzer (lint + trace)
Language Go (backend), Vue (frontend) TypeScript (Node.js 20+)
License Dual (MIT core, separate Enterprise license for gated code) MIT (forever)
Runs as Self-hosted server or Bytebase Cloud (SaaS) Yes, a single CLI binary, no server to run
Database engines Yes (20+: Postgres, MySQL, MongoDB, Snowflake, ClickHouse, more) Postgres only, by design
SQL review rule count 200+ (Bytebase's count, across all supported engines) 40+ migration-safety checks (Postgres-specific)
Standalone lint, no server required No (SQL Review calls a running Bytebase instance's API) Yes (works offline, no infrastructure)
Input: TypeORM, Prisma, Knex, Kysely, Sequelize, Drizzle No (raw SQL / VCS migration files only) Yes (built-in extractors)
Explicit Postgres lock-mode per statement No (flags patterns like "add column with default", no lock-mode label) Yes (every statement labeled)
Safe rewrite recipes in output No (rule description explains the risk, not the fix sequence) Yes (step-by-step expand or contract sequences)
Trace mode (live lock verification) No Yes (Docker, observes pg_locks)
DB-size-aware risk scoring No Yes (stats snapshot or read replica)
Auto-fix No Scoped: --fix applies a pure single-statement allowlist (adds CONCURRENTLY, missing SET timeouts); --fix --split scaffolds sibling migration files for multi-step recipes
Approval workflows Yes (Enterprise plan) Coming in pgfence Cloud (analyzer stays free)
RBAC / custom roles Basic RBAC on every plan; custom roles are Enterprise-only Coming in pgfence Cloud
Audit log Yes (7-day on Pro, unlimited on Enterprise) Coming in pgfence Cloud (hash-chained log)
Data masking / dynamic access control Yes (Enterprise plan) Not in scope, out of pgfence's problem
GitOps / GitHub integration Yes (sql-review-action, VCS-based workflow) Yes (composite GitHub Action)
LSP / editor integration No Yes (LSP + VS Code extension)
Pricing Free (Community, includes SQL Review) / $20 per user per month (Pro) / custom (Enterprise) Free (CLI, forever) / pgfence Cloud pricing not yet published

Where pgfence is honestly stronger

  • Zero infrastructure. pgfence is a CLI you install and run in CI in under a minute. Bytebase's SQL Review, even the free Community tier, calls the API of a running Bytebase server, so you are standing up (or paying for) a platform to get a lint result. If all you want is a fast pre-merge check, that is a heavier lift.
  • Postgres lock-mode depth. pgfence names the exact lock mode each statement takes, what it blocks, and prints the safe rewrite recipe in the same report. Bytebase's overlapping rules ("Disallow add column with default", "Disallow add NOT NULL constraints to an existing column") flag the pattern and explain the risk in prose, but do not label the lock mode or hand you the expand/contract steps.
  • ORM migration files. pgfence extracts and analyzes SQL from TypeORM queryRunner.query(), Knex .raw(), Sequelize, Drizzle, and Prisma's generated migration.sql directly. Bytebase's SQL Review works against raw SQL and its own VCS-based project workflow.
  • Trace mode. pgfence can run a migration against a real, disposable Postgres instance in Docker and report the lock modes Postgres actually took, not just the statically inferred ones. Bytebase's SQL Review is static rule matching.
  • Genuinely free analyzer, no upsell path inside the CLI. Bytebase's Community tier is real and includes the 200+ rules, which is honest of them. But the product is built to grow into paid seats as your team does. pgfence's CLI and GitHub Action have no seat count and no paid tier of their own; the analyzer stays MIT forever regardless of what pgfence Cloud eventually charges for.

Where Bytebase is honestly stronger

  • The control plane already exists, today, at scale. Approval workflows, custom roles, unlimited-retention audit logs, JIT access, dynamic data masking: Bytebase ships all of it now, across 20+ database engines, with a five-year track record and 14,000+ GitHub stars. pgfence Cloud is on the roadmap, not shipped.
  • Multi-database. If your org runs Postgres alongside MySQL, MongoDB, Snowflake, or ClickHouse, Bytebase governs all of them from one place. pgfence is Postgres only, by design, and has no plans to change that.
  • A real UI for humans. SQL Editor, saved queries, project and environment management, a web-based approval inbox. pgfence is a CLI, an LSP, and a VS Code extension; it has no hosted dashboard today.
  • Broader rule surface. 200+ rules across naming, modeling, and general SQL hygiene, not just migration lock safety. If you want an org-wide SQL style guide enforced alongside safety checks, that is Bytebase's job, not pgfence's.

When to use both

These are not mutually exclusive. A team already running Bytebase for governance can still run pgfence in CI as a fast, zero-infrastructure first pass on Postgres migrations before they reach Bytebase's review queue, and use pgfence's ORM extractors if migrations live inside a TypeORM or Prisma project rather than as raw SQL. The reverse is also common during evaluation: start with pgfence's free CLI for lock-mode safety, and adopt Bytebase (or pgfence Cloud, once it ships) when the organization actually needs approval workflows and an audit trail, not just a linter.

When to choose Bytebase over pgfence

Pick Bytebase if any of these apply:

  • You need governance (approvals, RBAC, audit log, data masking) today, not on a future roadmap.
  • You manage more than Postgres and want one platform across engines.
  • You want a hosted UI for DBAs and reviewers, not just a CI check.
  • Your migrations are not tied to an ORM pgfence extracts from, and you are fine adopting Bytebase's own project and VCS workflow.

See also

  • Atlas vs pgfence: another platform with a policy engine, but schema-as-code and execution focused rather than governance focused.
  • pgrubic vs pgfence: the Python linter with 100+ rules and auto-fix, closer to pgfence's own category.
  • Squawk vs pgfence: the Rust linter with the most polished LSP among pure migration-safety tools.
  • pgroll vs pgfence: a migration executor, a different category again from both Bytebase and pgfence.