bablsoft/accessflow Quick start Get AccessFlow
Compare

AccessFlow vs Bytebase: reviewing every statement versus managing schema change

Bytebase and AccessFlow are both open-source tools that put a review step in front of a database, and both can be self-hosted, so they are often shortlisted together. They are built around different moments, though. Bytebase is a database change-management platform: migrations as code, rollouts across environments, a SQL editor alongside. AccessFlow is a proxy that every ad-hoc statement passes through, with a human or a policy deciding before it runs. This page sets the two side by side, including the editions each capability actually lives in.

Get AccessFlow All comparisons
How to read this page. Product names are the property of their respective owners, and AccessFlow (made by bablsoft) is not affiliated with or endorsed by any of them. Everything said about another product comes from that vendor's public documentation as it read on the date in Sources; where we could not find a capability documented, the table says Not documented rather than No.

The short version

In one line: Bytebase governs how the schema changes; AccessFlow governs what runs against the data. Both are open source, but only AccessFlow includes approvals, masking and just-in-time access without a paid edition.

Choose Bytebase when the thing you need to govern is the schema itself: schema-changing DDL that starts life in a pull request, gets linted against a couple of hundred rules, rolls out through development, staging and production, and can be rolled back. Choose AccessFlow when the thing you need to govern is what people and automated agents run against live data day to day, reads included, and you want each of those statements parsed, risk-scored, routed to an approver and executed under masking and row-level security, with a tamper-evident record of the whole exchange. The two overlap in the middle, where Bytebase's SQL editor, its query permissions and its just-in-time grants meet AccessFlow's editor and review queue, and that overlap is where most of this page lives.

The other axis is licensing. Both projects publish their source, but Bytebase's approval workflow, dynamic masking, just-in-time access, SCIM user provisioning and most single sign-on options are Enterprise features, while AccessFlow ships one Apache 2.0 edition with nothing held back. If you are comparing the free tiers, compare Bytebase Community with all of AccessFlow, and the picture is quite different from comparing the two Enterprise-sounding feature lists.

Side by side

CapabilityAccessFlowBytebase
Licence and sourceApache 2.0, one edition, full sourceMIT for most of the code, with the enterprise directories under a separate licence
HostingSelf-hosted only (Docker Compose, Helm, source); no hosted editionSelf-hosted (Docker, Kubernetes) or Bytebase Cloud; the Pro plan is cloud-only
How people reach the databaseAccessFlow's web editor, REST API or Model Context Protocol (MCP) server; no wire protocol or driver, so native clients cannot connect through itBytebase's web SQL Editor; native-client passthrough: Not documented
Engines18 connectors across relational, warehouse, document, key-value, wide-column, search and graph enginesAround 25, including TiDB, OceanBase, CockroachDB, Spanner, Redshift, Hive, StarRocks and Cosmos DB
Every statement reviewed before it runs✓Yes: parse, AI risk score, routing policy, approval, then execution, for reads and writes alike✓Change workflow: yes. Ad-hoc SQL Editor queries run on permission; a just-in-time grant can cover one approved read-only statement
AI risk review of the statement✓Yes, with Anthropic, OpenAI, Ollama, any OpenAI-compatible endpoint or Hugging Face, plus multi-model voting◐Risk levels are computed from statement type; an AI assistant helps write SQL. LLM review of a statement: Not documented
Approval chains and routing✓Multi-stage chains per datasource, plus ordered routing policies that auto-approve, auto-reject, require extra approvals or escalate◐Sequential multi-node custom approval, matched by condition and risk level (Enterprise)
Just-in-time, time-bound access✓Yes: self-service requests, automatic expiry, optional pre-approval of covered queries◐Yes: time-boxed roles from one week to a year, single-statement grants from one hour to seven days (Enterprise)
Break-glass with mandatory retro-review✓Yes: per-user, per-datasource, admins included; every admin is paged; a different admin must sign off afterwards?Not documented
Can requesters approve their own request✓Never, on any channel, for any role◐Setting, disabled by default
Written SQL review rules✓14 named rules for the relational engines, at off, warn or block per environment; a block forces human review and never rejects✓Over 200 lint rules (Community)
Column masking✓Yes: full, partial, hash, email and format-preserving strategies; admins are masked too unless explicitly revealed◐Yes: semantic types and exemptions (Enterprise); not available on every engine
Row-level security✓Yes: the statement is rewritten with a parameter-bound predicate, failing closed where an engine cannot?Not documented
Result export controls✓Yes: allow, watermark, row cap or deny per datasource, with the watermark baked in before signing✓Yes: export permission and a watermark setting
Audit and security event management (SIEM)✓Every query and decision; entries chained with a keyed hash; append-only writer role; Splunk, syslog, HTTPS and S3 Object Lock sinks◐Configuration and SQL query events with row data redacted, streamed as JSON to a SIEM (Pro and Enterprise); tamper-evidence: Not documented
Signed compliance reports✓Yes: PDF and CSV with a detached signature?Not documented
Session recording✕No: there is no interactive session; each statement is its own record?Not documented
Single sign-on and SCIM✓SAML 2.0, OAuth2/OpenID Connect (OIDC) (Google, GitHub, Microsoft, GitLab, generic OIDC) and SCIM 2.0, all included◐OAuth2, OIDC and LDAP (Enterprise; Google and GitHub on Pro), SCIM (Enterprise); SAML: Not documented
Terraform provider✓Yes✓Yes
MCP server for AI agents✓Yes, for every engine, through the same review pipeline✓Yes, inheriting the user's permissions and masking
Governed API calls and CI/CD deployment gates◐Yes: outbound REST, SOAP and GraphQL calls (gRPC targets can be registered and reviewed but not yet executed), and a fail-closed deployment gate for pipelines?Not documented
Schema migrations and GitOps✕No: AccessFlow reviews DDL statements but ships no migration lifecycle✓Yes, the core product: releases, plans and rollouts from pull requests, batch changes, rollback
SSH, Kubernetes or desktop access✕No?Not documented

Included With caveats or in a paid edition Not available Not documented

Not documented means we could not find the capability in Bytebase's public documentation on the date in Sources; it does not mean the product lacks it. Enterprise and Pro follow Bytebase's published plan table.

Where each one sits in the path to the database

Bytebase's centre of gravity is the change pipeline. A developer writes a migration file in a branch, a pull request triggers lint and review, and once merged a CI job creates a release, a plan and a rollout that carries the change through each environment in turn, skipping anything already applied. Alongside that pipeline sits a SQL editor: a person with the right project role can run queries, write statements need a separate permission or go back through the change workflow, and results are masked according to the column's semantic type. Access requests, whether for a time-boxed role or for a single approved statement, go through the same custom approval flows as changes, and those flows can be conditioned on a computed risk level.

AccessFlow's centre of gravity is the individual statement. There is no migration repository and no environment promotion; instead every query that anyone submits, through the editor, the REST API or an AI agent talking MCP, is parsed before anything else happens, so that the statement type and the exact tables and columns it touches are known up front. AccessFlow checks them against the datasource's allow-list and, on the relational engines, its written review rules, asks the configured AI provider for a risk score and a list of issues, and hands the result to a routing policy that decides whether the request is auto-approved, auto-rejected, escalated or sent to a review plan for people to decide. When it finally runs, it runs through the proxy: row-level security rewrites the predicate, masking rewrites the result, export rules decide what may leave, and the audit entry is chained to the previous one with a keyed hash so that anyone editing history later can be caught.

The honest gap on AccessFlow's side is connectivity. Bytebase documents no native-client passthrough either, but a Bytebase user still has the migration pipeline as their main road into production, whereas AccessFlow expects the statement to arrive through its own front doors. If your team lives in DataGrip and wants to keep doing so, neither product changes that today, and AccessFlow's roadmap lists a native wire-protocol gateway as unscheduled work rather than as a promise.

Where AccessFlow is the better fit

  • You need reads reviewed, not just writes. A support engineer's SELECT against a customer table is a data-exposure event; AccessFlow scores and routes it like anything else, and can auto-approve the routine ones by policy so the queue stays short.
  • You want an AI opinion on the statement itself. The analyzer reads the SQL and returns a risk score, the issues it found and a suggested rewrite, from whichever provider you choose, including a local model when nothing may leave the building.
  • Row-level security and export governance matter. Bytebase documents column masking; AccessFlow additionally rewrites the query so a user only receives the rows they are cleared for, and can watermark, cap or deny what leaves as a file.
  • You need an emergency path with consequences. Break-glass runs the statement immediately under every data control, pages every admin, and cannot be closed by the person who used it.
  • You want all of it in the free edition. Approval chains, masking, just-in-time access, SCIM and SAML are included in the only edition AccessFlow has; in Bytebase they are Enterprise features.
  • Databases are not your only governed surface. The same pipeline gates outbound API calls and CI/CD releases, with one audit trail behind all three.

Where Bytebase is the better fit

  • Schema migrations as code. If DDL should live in a repository, be reviewed in a pull request and roll out through environments as a release with a plan and a rollback path, that is Bytebase's core product and AccessFlow has nothing comparable.
  • Migration linting at scale. Bytebase's catalogue of over 200 review rules, available in the Community edition, is built for catching a bad ALTER TABLE before it reaches staging; AccessFlow's fourteen rules are aimed at ad-hoc statements.
  • Multi-environment schema management. Batch changes across databases that share a schema, state-based schema definitions, and synchronisation between environments are Bytebase features with no AccessFlow equivalent.
  • Engines AccessFlow does not connect to. TiDB, OceanBase, CockroachDB, Spanner, Redshift, Hive, StarRocks and Cosmos DB are on Bytebase's list and not on AccessFlow's, though any JDBC engine can be added to AccessFlow by uploading a driver.
  • One tool for change management and querying. If you want the migration pipeline and the day-to-day SQL editor from a single vendor with a single permission model, Bytebase covers both; AccessFlow only covers the second.

Licence, editions and what is gated

Bytebase's repository carries an MIT licence for the bulk of the code, with its enterprise directories and the code that enables plan-gated features under a separate enterprise licence. The published plan table draws the line clearly: the Community edition is free for up to twenty users and ten database instances and includes the change workflow, GitOps, the SQL review rules and the AI assistant; the Pro plan adds Google and GitHub sign-in and a short audit-log retention window and is cloud-only; and custom approval workflows, dynamic data masking, just-in-time access, SCIM, the wider OIDC and LDAP sign-in options, custom roles and environment tiers are Enterprise. Audit logging itself is documented as a Pro and Enterprise feature.

AccessFlow is released under the Apache 2.0 licence in one edition. There is no seat count, no instance count, no cloud-only tier and no feature held back for a commercial version: the approval chains, routing policies, masking, row-level security, break-glass, SAML, SCIM, audit sinks and signed compliance reports on this page are all in the same download. The trade-off is the obvious one: there is no vendor to buy support from, and the project is younger and narrower than Bytebase. What is available now and what is planned →

Running both

Because the two govern different moments, running them together is coherent rather than redundant. A common arrangement is Bytebase for schema change, with migrations flowing from pull requests through its rollout pipeline, and AccessFlow in front of the same databases for everything that is not a migration: the ad-hoc read a support engineer needs, the one-off UPDATE an on-call engineer wants approved at three in the morning, the queries an AI agent submits, and the API calls and deployments that need the same sign-off. Each keeps its own audit trail, and AccessFlow's can be streamed to the same SIEM as Bytebase's JSON log. If you only have budget or attention for one, the question to ask is whether your risk lives in the schema or in the data.

Sources

Checked on . AccessFlow's own claims come from its source repository and the pages of this site they link to. If a vendor's documentation has changed since, please open an issue and we will correct the page.